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ABSTRACT 


There are many products and techniques which could be used to help manage 
a network of DPCX/DOSF systems; choosing between them, however, and com- 
bining a selection of them into a coherent system, may be a complex task. 


The purpose of this guide is to help the network manager select the pro- 
ducts and techniques he needs, and special attention is paid to three 
areas in which DPCX/DOSF systems have unique requirements: 

° software Management 

. Configuration Management 

° Problem Management 

This guide is essentially a practical document, not a theoretical one, and 
offers detailed guidance on how to make best use of the tools. It places 


particular emphasis on centralised network management techniques, and 
includes tested procedures for using them, with working examples. 


Abstract iii 
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PREFACE 


ABOUT THIS BOOK 


This manual suggests procedures for managing a small to medium sized net- 
work of 8100s running DPCX and text applications. It lays particular 
emphasis on techniques which enable personnel using the central site host 
computer effectively to maintain, control and diagnose problems on sys- 
tems which are physically remote. 


This book assumes a working knowledge of DPCX with DOSF and familiarity 
with SNA networks. It does not teach basic skills, but seeks to draw 


together a number of diverse techniques, and, where they overlap, to 
assist the user in selecting between them. 


WHO SHOULD READ THIS BOOK 

The intended audience for this publication is data processing personnel at 
the central computer site, particularly: 

e Systems programmers involved in maintaining distributed software. 


: Network administrators or others involved with the configuration of 
the 8100 systems. 


e Help Desk or other user support staff with involvement in 8100 problem 
determination. 


This book does not set out to formulate procedures for 8100 Control Opera- 
tors or DOSF/DISOSS operators. 7 


HOW THIS BOOK IS ORGANISED 


The manual is organised into an introduction and four major parts: 


° The introduction defines more precisely the environment for which the 
guidance in this manual is intended, and lists those things which are 
considered pre-requisite to being able to use it. 


e Part 1 considers in detail a methodology for the maintenance of soft- 
ware in distributed DPCX/DOSF systems. 


° Part 2 investigates the data which should be recorded about the con- 
figuration of DPCX/DOSF systems and precautions which should be taken 
to maintain their integrity. 


e Part 3 discusses aspects of problem determination unique to DPCX and 


DOSF systems, and how such problem determination may be carried out 
from the central site. 


Preface V 


e Part 4 consists of appendices which contain background information on 
some topics, and sample aids related to the procedures in the main 
body of the book. 


RELATED PUBLICATIONS 


This manual collates network management techniques which are separately 
documented in a number of different publications. Each manual referred to 
in this book is listed in the "Bibliography" on page 187, with its forms 
number and a brief description. 
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1.0 INTRODUCTION 


This document has been designed to assist the user who is installing or 
who Fas recently installed a network of 8100s for text applications. It 
seeks to identify the products and procedures which are necessary to oper- 
ate effectively in such an environment. 

The typical installation which this document is intended to aid is 
described below. As networks become larger, or add other applications, 
additional network management tools may become necessary. Where possi- 
ble, pointers are provided to identify such new requirements arising from 


increasing network complexity, and possible ways of meeting the need, but 
these are not investigated in detail. 


1.1 THE TYPICAL NETWORK ENVIRONMENT 


The following assumptions are made about the network: 


1. The 8100s are all running a similar text application, using DPCX with 
DOSF and DISOSS for document filing and distribution. 


2. There are approximately ten 8100s in the network. 


3. All 8100s are connected to a host System/370, 4300, 303x or 308x, run- 
ning OS/VS2 MVS, OS/VS1 or DOS/VSE control programs. ? 


4. The SNA network is based on ACF/VTAM and ACF/NCP, and may use the mul- 
ti-system networking facility. 


5. The SNA network is already in place or being put in place. 
6. The following CNM products are installed: 


° Network Communications Control Facility (NCCF), 5735-XX6, release 
2 or later, with the Terminal Access Feature (TAF). 


: Network Problem Determination Application (NPDA) Version 2, 
5668-983. 


° Host Command Facility (HCF) Version 2, 5668-985. 
° Host Prep, 5735-XR3, release 4.1 or later. 


7. Any required DB/DC subsystem (such as CICS or IMS) is generated with 
the DPCX support needed. 


8. The host job entry subsystem is configured to support DPCX RJE. 


9. One 8100 is available for testing and development (it is hereafter 
called the test 8100), but it may also be used for production work. 


The procedures in this document have been tested with MVS, but should 
work except where otherwise noted for 0S/VS1 and DOS/VSE. The JCL giv- 
en is that for MVS. 
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The test 8100 is not necessarily at the host site, but it is accessi- 
ble to personnel responsible for installing and maintaining DPCX, and 


there is access to host CNM products and batch job submission facili- 
ties (for example, using DPCX DSC and RJE respectively). 


The test 8100 has an 8809 tape unit attached, but no other 8100 need 


have a tape. | 


The skills of the 8100 control operators on the production machines 
are limited to text functions, and following documented procedures or 
verbal instructions. 


A centre of competence exists to assist 8100 control operators with 
day-to-day problems with DPCX and DOSF. This centre of competence is 
elsewhere referred to as the Help Desk. It may be as small as a single 
person, perhaps the network administrator also responsible for plan- 
ning and configuring DPCX/DOSF systems. 


ASSIST installation, and hence system defined categories, has been 
used in the initial installation of each DPCX system. 
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PART 1: SOFTWARE MANAGEMENT 


This part of the manual should be read by system programmers or network 
administrators responsible for maintaining software on 8100 DPCX/DOSF 
systems. 


PART 1: SOFTWARE MANAGEMENT 3 


4 DPCX/DOSF Network Management 


2.0 INTRODUCTION TO SOFTWARE MANAGEMENT 


The management of software in a network of distributed systems must 
address the following areas: 


e Change control: the orderly testing and application of modifications 
to IBM and user programs, with capability for regression if necessary. 


e Distribution: the mechanics of applying software changes to a number 
of geographically separated systems. 


e Recording: the maintenance of accurate records of the level of the 
software at each system; what modifications have Leen applied, and 
when. 


Whilst the adoption of proper change control procedures is strongly advo- 
cated, there are no considerations which are specific to the environment 
of a network of DPCX/DOSF systems. In consequence, such procedures are not 
discussed here, but if you wish to know more, ask your IBM representative 
for an appropriate installation management manual. The Informa- 
tion/Management feature of the Information/System program product, 
5735-0ZS, described in "Overview of the Information/Management Program 
Product" on page 90, contains functions to assist in change control. The 
processes of distribution and recording are discussed below. 


For 8100 DPCX/DOSF systems it is necessary to distinguish between two 
classes of software, each of which will require different installation and 
maintenance procedures. 


First, there is System Software: this includes the DPCX operating system 
itself, (and, prior to DPCX Release 3, its feature #6001), and DOSF. These 
programs are distinguished by being delivered on diskette 2D for installa- 
tion by the procedures detailed in the DPCX DOSF Installation manual. 


Programs in the second category are hereafter referred to as Application 
software. They include DISOSS, DIF and any user-written DPCX code, and are 
distinguished by being written to run as DPCX Function Programs. They are 
distributed on tape for installation via the host System/370, or on 128 
byte sectored diskette 1 for installation via the DPCX SYSBDISK System 
Service. 


The different techniques to be used with these two categories of software 
are described in two further chapters in this part of the manual, under 
"Network Management of System Software’ on page 7 and "Network Management 
of Application Software" on page 59. 


Introduction to Software Management 5 


6  DPCX/DOSF Network Management 


3.0 NETWORK MANAGEMENT OF SYSTEM SOFTWARE 


The techniques used for the software management of the system programs 
vary according to the type of maintenance being handled. The following are 
discussed separately: 


° Initial installation of the DPCX and DOSF products throughout the net- 
work and subsequent update installations to new releases. See "Base 
Code Initial and Update Installation." 


° Application of PTFs throughout the network. See "PTF Management for 
System Software’ on page 19. 


3.1 BASE CODE INITIAL AND UPDATE INSTALLATION 


The guidance in this section does not seek to teach you about DPCX and 
DOSF planning and installation. These topics are covered in the DPCX Plan- 
ning manual, the DOSF Planning manual and the DPCX DOSF Installation manu- 
al. What is documented here are specific techniques to minimise the skills 
and involvement required in the installation process at the production 
8100 sites. The intention is that when the operators first sign on to the 
8100 the DPCX/DOSF system should be fully operational. 


The processes of initial and update installation are discussed separately 
in "DPCX/DOSF Initial Installation" on page 8 and "DPCX/DOSF Update 
Installation" on page 12. 


. Besides being required on a new 8100, an initial installation may be 
desirable if you want to make substantial changes to the layout of 
disk space when, for instance, an extra disk has been added. It cre- 
ates an entirely new DPCX/DOSF system, destroying entirely anything 
that was there before. If you decide to overwrite an existing system 
in this way, then the guidance in ''PART 2: CONFIGURATION MANAGEMENT" 
on page 77 may be of use to you in making the transition. 


° An update installation will upgrade software to the next release, but 
will leave unaltered all user documents and data, and most configura- 
tion information. 


3.1.1 INTRODUCTION TO NIM 


DPCX release 3 introduces a capability for installing DPCX and DOSF base 
code from the host. This function requires the Distributed Systems Execu- 
tive program product at the host system. It also needs at least a minimal 
installation of DPCX release 3 or later at any 8100 which is to receive 
code across the network. 


NIM works by distributing images of the installation diskettes to the 
8100s to be installed. These images are saved on disk, and NIM supports 
transmission of special command lists to an 8100 to cause installation to 
be performed from disk images of the diskettes. 
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(3) 
(1) 


PRODUCTION 
8100S 


Figure 1. Installing DPCX and DOSF with NIM: this is a schematic of 
the process of installing software with the Network 
Installation Management capability of DPCX release 3. 


NIM would be used in a network of 8100s as illustrated in Figure 1 on page 
8. The numbered steps are as follows: 


1. DSX is used to retrieve images of the installation diskettes from the 
test 8100 to the DSX holding file. The data may be kept here to 
install future 8100s. Note that in this step the test 8100 merely 
serves as a diskette reader: the contents of the diskettes are not 
stored at the test 8100, but are simply transmitted to DSX. 


2. The diskette images may be transmitted first to the test 8100 system 
and installed here to verify the NIM installation process and the new 
release. 


3. The diskette images are transmitted to production 8100 systems and 
installed. 


As well as transmitting DPCX and DOSF program code, DSX can also retrieve 
to the host a set of SYSCONFG and SYSIMOD configuration data, customised 
with the SYSRCNFG System Service. DSK can send these records to an 8100 
and instruct NIM to copy them into the system configuration dataset. 


NIM also has a capability to allow a DPCX configuration IPL using the host 
as the configuration device, so that configuration of a newly installed 
system may be completed from the host. 


3.1.2 DPCX/DOSF INITIAL INSTALLATION 


Three techniques are available for an initial installation of DPCX and 
DOSF: 
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. Installation from diskettes using ASSIST 
e ‘Manual’ installation from diskettes, not using ASSIST 


° Installation from the host, using the Network Installation Management 
(NIM) capability of DPCX release 3. 


Of these three techniques, installation using ASSIST is strongly recom- 
mended unless very special requirements necessitate the 'manual' instal- 
lation. From DPCX release 3 onwards considerable flexibility in 
re-allocation of bit maps is possible on an ASSIST installed system, so 
making use of ASSIST practicable in all but very exceptional cases. A 
‘manual’ installation will require more work to configure an operational 
system. Use of NIM is not suggested because it does not perform an ASSIST 
installation and so does not configure the bitmaps in a suitable way for a 
production DOSF system, and it cannot be used without first installing the 
DPCX release 3 diskettes on the 8100. It is considerably easier to use the 
ASSIST installation rather than either of the alternatives. 


The ASSIST installation is very well documented in the DPCX DOSF Installa- 
tion manual and in the DOSF Installation Card for ASSIST. Its use will 
result in an almost fully configured system with no more skill required at 
the 8100 site than the ability to follow the instructions in the ASSIST 
installation card. The SYSIMOD host parameters and the SYSHOST parame- 
ters, however, will not be configured. The paragraphs which follow 
describe a technique by which this can be accomplished from the host, and 
in consequence allow all remaining customisation to be performed without 
DPCX skills at the 8100 site. It uses part of the NIM function of DPCX 
release 3. 


As pre-requisites to using this technique, you need the following: 


ad DPCX release 3 or later; presumably just installed with ASSIST along 
with DOSF on a new 8100. 


° All terminals to have been powered on, and all loops and links to have 
been connected during that installation. 


e The DPCX LU with local address 02 defined in the NCP. 
e Host Command Facility (HCF) installed at the host. 


° Instructions for the control operator to reply to the IPL prompts on 
the 8100 Basic Operator Panel (BOP). 


Having installed with ASSIST*, follow the steps set out below: 


1. Have the control operator perform a configuration IPL designating the 
host as the logon device thus: 


2 Ensure that, during the ASSIST installation process, PTF UC01830 is 
installed. This PTF is on PTF Diskette 28 or above, and without it, 
the subsequent configuration IPL to the host may fail with a code 4934 
displayed on the BOP. This will occur in the following circumstances: 
if the ASSIST installation process finds more than one SDLC adaptor 
without powered-on devices attached, it cannot guess which of them is 
intended to be used as the host link. Therefore, no host link will be 
configured, and without PTF UC0O1830 the 4934 error will subsequently 
occur. If ASSIST is able to configure a host link, the configuration 
IPL to the host will work without the PTF. 
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e Set the IPL mode select switch to ‘manual’ , and the security key- 
lock (if fitted) to ‘enable’. 


¢ Press the IPL button. 


. When the BOP displays 0200, key in 13dd and press the Enter Data 
button. 13dd designates the IPL disk address, and so the reply to 
this prompt would normally be 1380 or 1384 depending on processor 
model. 


* When the BOP displays 0201, key in 9A00 and press the Enter Func- 
tion button. 


. When the BOP displays 43AA, key in 0001 and press the Enter Func- 
tion button. 


od When the BOP displays 43AB, key in D7hh and press the Enter Func- 
tion button. D7hh designates the host adaptor address; for 
instance key in D710 if the host adaptor is the first port on the 
first 8101. 


° When the BOP displays 43CD, key in the host link parameters. These 
are fully described in the DPCX DOSF Installation manual. Press 
the Enter Function key. 


° IPL eee process to completion, when the BOP display will be 
blank 


For the configuration IPL, host processing bypasses validation of the 
host SSCP and batch applications against the SYSHOST tables. The LU 
with local address 01 is available for type 1 batch (NIM functions 
only) and that with local address 02 for HCF. 


At a host terminal, sign on to HCF. Acquire the DPCX LU with local 
address 02. 


The DPCX logon menu will appear. Sign on as the control operator, 01 
with password of OPIDO1. 


Because this was a configuration IPL, you will be forced to run SYS- 
CONFG. Use option 1 to ensure that the host adaptor is correctly con- 
figured. Use option 3 to process the configuration. 


SYSCONFG concludes by IPLing the 8100, and your HCF session will be 
lost. This IPL remembers the information specified previously and 
will activate the host again in a similar fashion, but now all type l 
batch functions are available to the LU with local address 01. 


From HCF, acquire the LU with local address 02 as before. 
When the DPCX logon menu appears, sign on as the control operator. 


Using SYSIMOD, ensure that the host configuration information is set 
correctly. 


Define the SYSHOST parameters and the PROC to be executed at system 
reset. Use one of the two procedures that follow. The first may be 
simpler if only one 8100 is involved; the second may be preferable if 
several installations are to be performed and DSX is available. (Take 
note of the SPE required for DSX, mentioned in "“DPCX/DOSF Update 
Installation" on page 12.) 
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a. Using HCF only: 


e Use the DEFINE HOST command with ID, BATCHID and LUPGMID oper- 
ands to establish the SYSHOST parameters. 


e Using SYSEDIT, define a procedure named IPLPROC containing an 
ENABLE HOST command. 


e Issue the command DEFINE STARTUP=IPLPROC to identify the pro- 
cedure to DPCX. 


b. Using HCF and DSX: 


e Issue the command ENABLE HI=2 to allow a- second 
host-:nitiated session. 


e Run a DSX job such as that illustrated in Figure 3 on page 13 
to transmit PROCs 'DEFHOST' and 'IPLPROC' to DPCX. Sample JCL 
procedures are shown in Figure 2 on page 12. 


e Issue the command DEFINE STARTUP=IPLPROC to identify the sys- 
tem reset procedure to DPCX. 


e Enter the command DEFHOST to run that PROC. 


Note: If at this point the DEFHOST command is not recognised, 
use SYSEDIT to access the PROCs and file them again. The DEF- 
HOST command should now work. | 


9. Enter the command DISABLE HOST,HI 
10. Use SYSIMOD option 8 to IPL DPCX. 


ll. After this IPL, the DPCX terminals should be active as well as the 
fully configured host link. HCF may now be used to communicate with 
the LUs designated by the installation, to perform further customisa- 
tion. 


If any problems occur with the host link during this procedure, DPCX will 
automatically re-enable the host link if it fails while the configuration 
IPL is in effect. If, for any reason, you need to re-IPL DPCX before SYS- 
CONFG has processed, have the control operator perform the configuration 
IPL again. If DPCX needs to be IPLed before you have established the host 
parameters, have the control operator commence the IPL as for the config- 
uration IPL, but in place of '9A00' enter '9A80'. This will re-establish 
the special host environment which existed after SYSCONFG IPLed DPCX. 


If, after the host parameters have been set and DPCX been IPLed by SYSIMOD 
option 8, the 8100 does not come active to VTAM, it may be because the NCP 
has discontacted it after the IPL. Once the network resources have been 
activated, instruct the control operator to perform a primary IPL at the 
8100; this time the 8100 should come active to VTAM. 


After the installation, DSX may be used to transmit DOSF sample (or other) 
PROCs to DPCX. These would have been previously retrieved to the host 
(with DSX) from the test system. Alternatively, these may be loaded 
directly from diskette. The spelling dictionaries will have to be loaded 
from diskette at the 8100 site as shown on the DOSF Installation Card for 
ASSIST. 
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THIS PROC IS USED FOR DSX BATCH FUNCTIONS 


//DSX PROC 

//PREP EXEC PGM=DSXPREP 

//STEPLIB DD DSN=DSX2 .DSXLOAD , DISP=SHR 
/ /DSXCMF DD DSN=DSX2 .DSXCMF , DISP=SHR 
//DSXLIB1 DD DSN=DSX2 .DSXLIB1,DISP=SHR 
//DSXLIB2 DD DSN=DSX2 .DSXLIB2 , DISP=SHR 
//DSXDATA DD DSN=DSX2 . DSXDATA, DISP=SHR 
//DSXTCF DD DSN=DSX2 .DSXTCF , DISP=SHR 
//SYSPRINT DD SYSOUT=A 

//DSXPRINT DD SYSOUT=A 

// PEND 

//* 

//* THIS PROC IS USED FOR DSX TRANSMISSIONS 
//* 

//DSXXMIT PROC 

//XMIT EXEC PGM=DSXTMOO0O0 

//STEPLIB DD DSN=DSX2 .DSXLOAD , DISP=SHR 
//DSXCMF DD DSN=DSX2 . DSXCMF , DISP=SHR 
//DSXLIB1 DD DSN=DSX2 .DSXLIB1,DISP=SHR 
//DSXLIB2 DD DSN=DSX2 .DSXLIB2 , DISP=SHR 
//DSXDATA DD DSN=DSX2 . DSXDATA , DISP=SHR 
//DSXTCF DD DSN=DSX2 .DSXTCF , DISP=SHR 
//DSXCWK DD DSN=DSX2 . DSXCWK , DISP=SHR 
//SYSPRINT DD SYSOUT=A 

//DSXPRINT DD SYSOUT=A 

//DSXSTAT DD DSN=DSX2 .DSXSTAT , DISP=SHR 
// PEND 

Figure 2. OS/VS JCL for executing DSX: sample JCL procedures 


showing the DSX datasets required to use the Network 
Installation Management capability of DPCX Release 3. 


3.1.3 DPCX/DOSF UPDATE INSTALLATION 

The same three techniques are available for an update installation as for 
an initial installation: 

. Installation from diskettes using ASSIST. 


e ‘Manual’ installation from diskettes, not using ASSIST. 


ad Installation from the host, using the Network Installation Management 
(NIM) capability of DPCX release 3.? 


Note that the requirements and restrictions described here relate to 
the use of NIM to update-install a DPCX/DOSF R3 system on an older 
DPCX/DOSF R3 system. This is probably not a common requirement; the 
real intention of NIM is to ease the installation of future DPCX/DOSF 
releases on aR3 base. It may be that the restrictions, described here 
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/ /DSX JOB 

// EXEC DSX,PARM='FUNCTION=CMFMAINT' 

//SYSIN DD * 
vedere AFTER CONFIGURATION IPL, WE MUST USE LOCADDR 01 
CHANGE MASTER CLUS=TEXTAB , BATCH=INTXABO1 

ADD CLIST ID=((DEFHOST,1,0)),CLUS=TEXTAB 

ADD CLIST ID=((IPLPROC,1,0)),CLUS=TEXTAB 

END 


/ ve 

// EXEC DSX,PARM='FUNCTION=LIBMAINT' 

//SYSIN DD ¥ 

REPLACE CLIST ID=(DEFHOST,1,0),CMD='*PROC', 
CMD='DEFINE HOST,ID=11', 
CMD='DEFINE HOST,BATCHID=SIRF' , 
CMD='DEFINE HOST ,BATCHID=DSx' , 
CMD='DEFINE HOST, LUPGMID=(10,958)', 


Pa OS SO PS 


CMD='DEFINE HOST, LUPGMID=(52,932)', 

CMD='DEFINE HOST, LUPGMID=(55 ,932)',CMD='*EXIT' 
REPLACE CLIST ID=(IPLPROC,1,0),CMD='**PROC', 

CMD='ENABLE HOST, LU=(1,64) ,HI=3',CMD='*EXIT' 


va 


~ END 


/* 

// EXEC DSX,PARM='FUNCTION=DEFSESS' 

//SYSIN DD * 

DEFINE SESSION CLUS=TEXTAB , TIME=0900 , DISP=(NEW , DELETE) 
REPLACE CLIST ID=((DEFHOST,1,0)),NEWNAME=SYSPROC .DEFHOST 
REPLACE CLIST ID=((IPLPROC,1,0)),NEWNAME=SYSPROC. IPLPROC 
END 

//XMIT EXEG DSXXMIT 

/ EXEC DSX,PARM='FUNCTION=CMFMAINT' 

//SYSIN DD * 

wieikee RESTORE BATCH LU FOR NORMAL OPERATIONS 

CHANGE MASTER CLUS=TEXTAB , BATCH=TEXTAB11 

END 


/ 
// 
Figure 3. DSX control statements to send PROCs to a DPCX 


system: these statements will cause DSX to transmit the 
DEFHOST and IPLPROC PROCs to the 8100 known as TEXTAB. 


A ‘manual’ update installation should not be performed on an ASSIST 
installed system; it cannot be done without first setting off the ASSIST 
bit with SYSIMOD. Conversely an ASSIST update installation cannot be per- 
formed on a system not installed with ASSIST. Hence if installing from 
diskettes, use ASSIST on an ASSIST system, but the 'manual' update instal- 
lation on a non-ASSIST system. 


The alternative is to use NIM to perform the update centrally from the 
host. Note that this procedure, which is described below, will handle only 


for R3 installation, will be different for installation of a future 
release; it is therefore very important to check the announcement and 
availability documentation for the release you are installing. 
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new releases of DPCX and DOSF, not new releases of IDTF or other 8775 
microcode features, nor a new version of the spelling dictionaries. It has 
the following prerequisites: 


°*  DPCX release 3 or later installed on a test (or 'source'’) 8100 
¢ DPCX release 3 or later installed on production (or 'target') 8100s 


e The diskettes for the new release of DPCX and/or DOSF available at the 
test 8100 site 


e Distributed Systems Executive Version 1 (5748-XXG) installed at the 
host system. In order to function with NIM, DSX Version 1 requires an 
SPE (Small Programming Enhancement) which is contained in PTF 
PTF90061"*. 


e The DPCX LUs with local addresses 01 and 02 defined in the NCP 
¢ Host Command Facility (HCF) installed at the host 


: Instructions for the control operator to reply to the IPL prompts on 
the 8100 Basic Operator Panel (BOP) 


Note: The NIM update install process overwrites any 8775 microcode fea- 
tures (including IDTF) which may be present in system dataset 1. They 
cannot be re-installed except by loading them from diskette at the 8100s 
which have been update installed. 


If you use IDTF and wish to use NIM for update installations, you may wish 
to use SASRAC (the Stand-Alone Save, Restore And diskette Copy program, as 
the DASD dump/restore program is known in DPCX release 3), to make a copy 
of an IDTF diskette when it is installed. The copy would then be available 
for re-installation after an update install. 


Note: The NIM update install process requires that ASSIST be set off at 
the target 8100s. This implies, of course, that future Update installa- 
tions cannot be done with ASSIST, but seems to have no other significant 
disadvantages. 


It is assumed that the test (or 'source') system is that known to DSX as 
TEXTAA; the examples show how to update target system TEXTAB. Several 
DPCX clusters could be identified to DSX as a group and update installed 
together. Sample DSX procedures as referenced in the examples of DSX con- 
trol statements are shown in Figure 2 on page 12. Follow these steps: 


1. Run the DSX control statements shown in Figure 4 on page 15, to 
retrieve images of the DPCX and DOSF program diskettes to the host. 
The control operator at the test system will receive messages, and a 
96FE prompt appears on the BOP display, asking for diskettes to be 
mounted. The diskettes are requested by feature code (9502 or 9500). 
If you use a national language are. mount that diskette in place 
of diskette 3 of 3 for DPCX (9502) or 2 of 2 for DOSF (9500). If an 
incorrect diskette is mounted twice in response to a prompt the func- 
tion will be terminated. 


The transmission of the diskette images may take several hours, 
depending on line speed, the load on the host system and so on. Dur- 


No support for the DPCX NIM functions has been anneunced in DSX Ver- 
sion 2 Release 1 (5668-986). 
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/ /DSX JOB 

// EXEC DSX,PARM='FUNCTION=DEFSESS' 

//SYSIN DD * 

DEFINE SESSION CLUS=TEXTAA , TIME=0900 , DISP=(NEW , DELETE) 

RETRIEVE DATASET ID=(SYSINST.RO3M00.9502) , FCTLNAME=DPCX , DISP=OLD 
RETRIEVE DATASET ID=(SYSINST.RO3M00.9500) , FCTLNAME=DOSF , DISP=OLD 
END 

/* 

//XMIT EXEC DSXXMIT 

// 


Figure 4. DSX control statements to retrieve installation 
data: these statements will cause DSX to retrieve 
installation diskette images from the DPCX system known 
as TEXTAA. 


ing the transmission the BOP displays a count as a progress indicator, 
and normal DPCX/DOSF operations may continue. 


2. On the target systems, 16 bitmaps have to be allocated to category 118 
subcategory 1. This may be difficult on a one-disk system, but the 
bitmaps are required only for the duration of the update install. If 
the impact to operation is acceptable, these bitmaps may be borrowed 
from the system spool: 


° Run SYSSPREC to ensure that all spool data is valid. 
° Print and delete all spool files. 


° All but the first bitmap in category 122, subcategory 1 should now 
be empty. Using SYSCAT option 1, re-assign the last 16 to category 
118, subcategory 1. (An ASSIST system has over 20 bitmaps in cate- 
gory 122, subcategory 1) 


This can be done even if system assigned categories are in effect. 


On systems with two or more disks these bit maps probably can be found 
in category 1 subcategory 1; you may wish to allocate them permanently 
to category 118 when you initially install the system. 


3. On the target systems, ASSIST must be set off using SYSIMOD option 1 
suboption 8. The NIM update install cannot be performed if ASSIST is 
on. After setting ASSIST off, you will not be able to use ASSIST to 
update install your system (so you must choose between ASSIST and 
NIM), but there will be no impact to its operation. 


4, Run the DSX control statements shown in Figure 5 on page 16 to send 
the installation diskette images to the target 8100(s). 
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16 


/ /DSX JOB 


EXEC DSX,PARM='FUNCTION=DEFSESS ' 


// 

//SYSIN. DD * 

DEFINE SESSION CLUS=TEXTAB , TIME=0900 , DISP=(NEW , DELETE) 
REPLACE DATASET ID=(SYSINST.RO3M00.9502) , FCTLNAME=DPCX, 


ORIGIN=TEXTAA 


REPLACE DATASET ID=(SYSINST.RO3M00.9500) , FCTLNAME=DOSF , 


ORIGIN=TEXTAA 


END 


ale 
PA’ 


// 
// 


XMIT EXEC DSXXMIT 


Figure 5. DSX control statements to send installation data: these 


statements will cause DSX to send installation diskette 
images to the holding area at the DPCX system known as 
TEXTAB. 


The installation diskettes are placed in a holding area on disk, con- 


tained in category 118. 


The transmission of the diskette images may take several hours. Dur- 
ing the transmission the BOP displays a count as a progress indicator. 
Normal system operation can continue. 


Perform the update install, by running the DSX control statements 
shown in Figure 6 on page 17 which sends an IPL command list to the 
target 8100(s). Of the commands, 9A05 causes DPCX to be installed 
from the holding area, and 9A08 has the same effect for DOSF. 9BO0 
causes immediate execution of the commands, irrespective of what oth- 
er tasks are running. 9B08 may be used in place of 9BO0O and defers 
execution of the commands until DPCX is shutdown and all operators 
signed off. 


The DPCX system(s) will perform a configuration IPL; that is, prompt 
43AB will be displayed at the BOP. 


Have the control operator perform the following: 


: When the BOP displays 43AB, key in D7hh and press the enter func- 
tion button. D7hh designates the host adaptor address; for 
instance key in D710 if the host adaptor is the first port on the 
first 8101. 


e When the BOP displays 43CD, key in the host link parameters. These 
are fully described in the DPCX DOSF Installation manual. Press 
the enter function key. 


e IPL should process to completion, when the BOP display will be 
blank. 


For the configuration IPL, host processing bypasses validation of the 
host SSCP and batch applications against the SYSHOST tables. The LU 
with local address 01 is available for type 1 batch (NIM functions 
only) and that with local address 02 for HCF. 


At a host terminal, sign on to HCF. Acquire the DPCX LU with local 
address 02. 
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10. 


11. 


12: 
13. 


14. 


15. 
16. 
17. 


//DSX JOB 

EXEC DSX,PARM='FUNCTION=CMFMAINT' 
//SYSIN DD * 
ADD CLIST ID=((SYSCSEQ,1,0)) ,CLUS=TEXTAB 
END 


/ te 
// EXEC DSX,PARM='FUNCTION=LIBMAINT' 
//SYSIN DD * 
REPLACE CLIST ID=(SYSCSEQ,1,0),CMD='9A05 ,9A08,9B00' 
END 
/ ri 

EXEC DSX,PARM='FUNCTION=DEFSESS ' 


// 

//SYSIN DD * 

DEFINE SESSION CLUS=TEXTAB , TIME=0900 , DISP=(NEW , DELETE) 
REPLACE CLIST ID=((SYSCSEQ,1,0)) 

END 

/* 

//XMIT EXEG DSXXMIT 

// 


Figure 6. DSX control statements to send IPL commands to a DPCX 


system: these statements will cause DSX to transmit the 
IPL commands to perform an update install, to the 8100 
known as TEXTAB. 


The DPCX logon menu will appear. Sign on as the control operator, 01 
with password of OPIDO1. 


Because this was a configuration IPL, you will be forced to run SYS- 
CONFG. Use option 2 to restore the configuration. 


This process concludes by IPLing the 8100, and your HCF session will 
be lost. This IPL remembers the information specified previously and 
will activate the host again in a similar fashion, but now all type l 
batch functions are available to the LU with local address 01. 


Acquire the LU with local address 02 as before. 

When the DPCX logon menu appears, sign on as the control operator. 

Use SYSIMOD option 2 to restore SYSIMOD information. Occasionally 
some data may be invalidated by the update installation. If so, use 


SYSIMOD option 1 to respecify. 


Verify that the SYSHOST parameters have not been invalidated by the 
update installation. Respecify them if necessary. 


Enter the command DISABLE HOST. 

Use SYSIMOD option 8 to IPL DPCX. 

After this IPL, the DPCX terminals should be active as well as the 
fully configured host link. HCF may now be used to communicate with 


the LUs designated by the installation, to perform further customisa- 
tion. 


If any problems occur with the host link during this procedure, DPCX will 
automatically re-enable the host link if it fails while the configuration 
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IPL is in effect. If, after the final IPL, the 8100 does not come active to 
VTAM, it may be because the NCP has discontacted it after the IPL. Once 
the network resources have been activated, instruct the control operator 
to perform a primary IPL at the 8100; this time the 8100 should come 
active to VTAM. 


After the update installation, DSX may be used to transmit new versions of 
the DOSF sample (or other) PROCs to DPCX. These would have been previously 
retrieved to the host (with DSX) from the test system. 


If bitmaps were borrowed from (for example) the system spool to allocate 
to the holding area, they should be returned using SYSCAT option 4 to 
delete category 118 and option 1 to assign them to category 122. 


3.1.4 APPLICATION OF PTFS 


After an initial or update installation, applicable PTFs should be 
installed. See "Installing PTFs after an Initial or Update Install" on 
page 55 for details of how to do this from the host. 


If DPCX and DOSF are installed from diskettes, you may wish to install the 
current fix package at the same time, from the PTF diskette, and using 
ASSIST if yours is an ASSIST installed system. In this case, you may need 
to do further work to remove any PTFs known to be in error, or to install 
additional corrective service PTFs. In either case, the methods in "Sug- 
gested Technique for Handling PTFs" on page 19 are applicable. | 
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3.2 PTF MANAGEMENT FOR SYSTEM SOFTWARE 


There are two techniques available for management of PTFs to DPCX system 
software. They are: 


1. Manual transmission of PTFs on diskette and application with the 
SYSPTF System Service. 


2. Host Prep SYSINFOREF (Subsystem Information Retrieval Facility, 
5735-XR3). 


Of the two possibilities, for any network with more than three or four 
8100/DPCX systems geographically distributed, use of SYSINFOREF is likely 
to be more productive. It is the primary tool discussed here. Information 
on the initialisation of SYSINFOREF and important notes on its operation 
are to be found in "SYSINFOREF Initialisation and Use" on page 125, and 
you should read this before attempting to use the product. 


3.2.1 SUGGESTED TECHNIQUE FOR HANDLING PTFS 


DPCX and SYSINFOREF provide between them a number of possible ways to 
achieve the end result of applying PIFs across the network. '"DPCX and 
SYSINFOREF PTF Handling Capabilities'’ on page 133 contains a summary of 
the different possible routes, and some comparison of the DPCX and the 
SYSINFOREF functions. The course recommended here employs only SYSINFO- 
REF, and was chosen because it will remain practicable as the network 
grows in size. Underlying the strategy is the assumption that one 8100 is 
designated as a test machine, on which the PTFs will be applied first, and 
not until any problems have been ironed out will they be sent to other, 
production DPCX systems. The steps are as follows; they are summarised 
schematically in Figure 7 on page 20. 


1. Get the PTFs into the SYSINFOREF datasets at the host. 
a. For preventive service PTFs, distributed on diskette: 
1) The test 8100 is used as a diskette reader. 
2) The PTFs are retrieved to the host. 
b. Corrective service PTFs are entered directly at the host. 

2. Send the PTFs to the test 8100 and install them there. When you are 
satisfied with the operation of the test machine, proceed to the n2xt 
step. 

3. Send the PTFs to the production 8100s and install them there. 

Although it is possible to perform installation of PTFs directly from 

diskette for the test system, it is preferable to retrieve them to the 

host and send them back to the test 8100 so that any problems that might 
arise in the PTF network distribution and installation process are discov- 


ered at this stage rather than when working with the production systems. 


The following terminology is employed when referring to PTFs in enor esos 
or DPCX datasets: 
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CORRECTIVE 
SERVICE 


SYS INFOREF 
DATASETS 
AT HOST 

SYSTEM 


(3) 


PRODUCTION 
81008 


Figure 7. Network application of PTFs: this is a schematic overview 
of installing PTFs across the network. 


° DPCX PTF dataset: this is DPCX system dataset 12, and PTFs are stored, 
maintained and tracked here until the next DPCX/DOSF update installa- 
tion. 


e DPCX system dataset 8: for DPCX releases prior to 3.0, this dataset is 
used to hold an image of a PTF diskette. 


: SYSINFOREF temporary PTF library, host temporary library or TEMPLIB:. 
is the logical library within a SYSINFOREF VSAM dataset where PTFs 
retrieved from an 8100 are initially placed. 


: SYSINFOREF PTF library or host PIF library: is the logical library 
within a SYSINFOREF VSAM dataset where PTFs are maintained at the 
host, and from which they may be sent to 8100s. 


3.2.2 INSTALLING PREVENTIVE SERVICE TO SYSTEM SOFTWARE 


This section suggests a procedure for applying PTF diskettes to DPCX and 
DOSF throughout the network. It aims to retain a central library of all 
PTFs at the host while the software levels to which they apply are current 
anywhere in the network. It assumes that SYSINFOREF has been initialised 
as in "Initialising SYSINFOREF" on page 127. Examples of control state- 
ments are included. Use the same JCL as that in Figure 61 on page 127. 
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(2) 


SYS INFOREF 
TEMPLIB 


SYS INFOREF 
(4) PTF (9) 
LIBRARY 
(5)— INSTALL (11) 
SYSINFOREF | 
RESPONSE _ | 
FILE 


(7) REMOVE | | 

PRODUCTION | 
8100S | 
HOLD —(10)—> 


Figure 8. Network application of preventive service: this is a 
schematic of the processes involved in installing a 
diskette of PTFs across the network. 


The steps are as follows. They are illustrated in Figure 8 on page 21. 


1. For DPCX prior to Release 3, IPL the PTF diskette to load its contents 
to system dataset 8 at the test DPCX system. 


2. Use SYSINFOREF to retrieve the PTFs on the diskette to the host tempo- 
rary PTF library from the test DPCX system. 


3. For all software levels in use in the network, copy applicable PTIFs 
from the host temporary PTF library to the host PTF library. 


4. Send the PTFs to the test DPCX system. 


5. Install the PTFs at the test DPCX system. 


Network Management of System Software 21 
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6. Determine the status of the test DPCX system: retrieve the PTF 
installation messages and test and list PTF status. 


IPL and test the operation of the test DPCX system until you are satisfied 
it is working normally. 


7. A PTF might have to be removed if it impacts operation. 


8. Retrieve the PTF removal messages from the test DPCX system if a PTF 
had to be removed. 


9. Send the PTFs to production DPCX systems. 


10. If any PTFs had to be removed from the test system, place these PTFs 
in HOLD status at production systems. 


11. Install the PTFs at the production systems. 


12. Determine the status of the production DPCX system: retrieve the PTF 
installation messages and test and list PTF status. 


The examples assume that there are some DPCX systems in the network with 
DPCX Release 2.1, feature 6001E and DOSF Release 2.0, and some with DPCX 
Release 2.2, feature 6001F and DOSF Release 2.1. Furthermore, the pro- 
duction systems have been defined to the SYSINFOREF machine list as being 
in class 1, and the test 8100 as being in a separate class, 900. (See "SYS- 
INFOREF Classes" on page 126 for a discussion of SYSINFOREF classes.) PTF 
diskette 23 is to be installed. 


For convenience of illustration, the sample control statements show the 
SYSINFOREF maintenance, generation, communication and response phases 
being executed consecutively within a single jobstream. As described in 
"SYSINFOREF Phases and Timing of Sessions’ on page 128, it may well be 
desirable to separate the execution of the different phases. 
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SYS INFOREF 
TEMPLIB 


SYS INFOREF 


PTF (9) 
LIBRARY 
(5)— INSTALL (qi) 


SYS INFOREF 
RESPONSE 


(7)———————__ REMOVE 
PRODUCTION 
8100S 
HOLD —(10)—> 
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Steps 1 and 2: Retrieve the entire diskette of PTFs to the host: On DPCX 
systems prior to Release 3, the diskette must first be IPLed as described 
in the DPCX DOSF Installation manual. For Release 3 or later systems, the 
PTF diskette should be loaded and ready in the reader on the 8100 before 
the SYSINFOREF job is initiated. Sample control statements follow in 
Figure 9. 


Note: Do not follow the instructions on the DOSF Installation Card for 
Assist - that process does more than is wanted here. 


GENERATE SYSID(TESTZZ10) 
RETRIEVE PTF DISKETTE 
END : 


STARTCOM SYSID(TESTZZ10) 
LIST RESPONSE (ALL) SYSID(TESTZZ10) 


Figure 9. Retrieving a PTF diskette with SYSINFOREF: these control 
statements will retrieve all the PTFs on a diskette to 
the host. 
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Step 3: Copy PTFs into the host PTF library: When PTFs are retrieved to 
the host, they are placed on the PTF temporary library (TEMPLIB). It is 
necessary to use the maintenance phase of SYSINFOREF to copy them into the 
host PTF library. Copy all PTFs for software levels and features that are 
present on DPCX systems in the network, as in Figure 10. 


Only those PTFs that are new on this ciskette, that is, which are not 
already on the host PTF library will be copied. The LIST PTF statement 
causes header information to be listed for each PTF in the host PTF 
library. This statement is not needed in Host Prep R5, since the ADD PTF 
statements will cause the required information to be reported. Separate 
copies of PTFs exist in the library for each level or feature to which 
they apply. Note the identification of the diskette for the PTFs just 
loaded; you will need to code this in the control statements which send 
the PTFs to DPCX systems. 


& ADD PTF LEVEL(RO2M01) 

& SYSID(TESTZZ10) 

& ADD PTF FEATURE (6001E) 

& SYSID(TESTZZ10) 

& ADD PTF FEATURE (DOSF20) 

& | SYSID(TESTZZ10) ; 
& ADD PTF LEVEL(RO2M02) 

& SYSID(TESTZZ10) 

& ADD PTF | FEATURE (6001F) 

& SYSID(TESTZZ10) 

& ADD PTF FEATURE (DOSF21) 

& SYSID(TESTZZ10) ; 
& LIST PTF ; 


Figure 10. Adding retrieved PTFs to the host PTF library: these 
control statements will add PTFs retrieved from DPCX to 
the host PTF library. PTFs are copied from the host 
temporary PIF library, for each software level and 
feature requested. 


At this point, the host PTF temporary library (TEMPLIB) may be deleted. 
The control statement in Figure 11 will accomplish this. If you have 
allocated a BHDWK2 dataset to contain the TEMPLIB you may take the faster 
option of deleting and redefining it with AMS, as described in the Host 
Prep SYSINFOREF Guide and Reference for Release 5.0 of Host Prep. 


& DELETE FILE TEMPLIB os 


Figure 11. Deleting the host TEMPLIB: this control statement will 
cause deletion of the entire contents of the host PTF | 
temporary library, that is, all PTFs retrieved from 
diskette. 
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Step 4: Send the PTFs to the test DPCX system: Note that SEND PTF 
requests are generated by level or feature. Assuming that the test system 
is at the later software level, generation is required for level RO2M02, 
feature 6001F and feature DOSF21°. The control statements shown in 
Figure 12 will do this. (If generation is performed for SYSID(TESTZZ10) 
only PTFs corresponding to level RO2M02 are sent - features are not 
included®.) 


The diskette identification was determined from the LIST PTF statement in 
Figure 10 on page 27. Only the new PTFs which were retrieved from that 
diskette are sent. Specify ACTIONCINSTALL) in order to be able to request 
installation of only the PTFs which have just been transmitted. 


GENERATE 
RETRIEVE 
SEND 


END 
GENERATE 
SEND 


END 
GENERATE 
SEND 


RETRIEVE 
END 
STARTCOM 
LIST 


& 
& 
& 
& 
& 
& 
& 
& 
& 
& 
& 
& 
& 
& 
& 
& 


LEVEL(R02M02) 

PTF 

PTF 

DISKETTE (CD20023) 


FEATURE (6001F) 
PTF 
DISKETTE (CD20023) 


FEATURE (DOSF21) 
PTF 

DISKETTE (CD20023) 
PTF 


SYSID(TESTZZ10) 
RESPONSE (ALL) 


MSG 


ACTION CINSTALL) 


ACTION (INSTALL) 


ACTION CINSTALL) 


MSG 


SYSID(TESTZZ10) 


b] 
e 
3 
3 
e 
3 
e 
3 


Figure 12. Sending PTFs to the test system: these control 
statements will transmit to the test 8100 PTFs which 
were loaded from the diskette. 


2 For SYSINFOREF with Host Prep Release 5.0, it is possible to generate 
by SYSID and pick up the feature PTFs. 
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Step 5: Install the PTFs on the test DPCX system: Specifying the ACTION 
option causes only those PTFs flagged for installation to be installed. 
These will be the ones previously transmitted. 


The PTF install process will not tolerate any concurrent activity in the 
DPCX system, including a host session with SYSINFOREF. SYSINFOREF there- 
for sets a flag in the DPCX system requesting installation; this can occur 
either at DPCX shutdown or at IPL time. If shutdown is chosen, the con- 
trol operator must properly close down active tasks and request shutdown 
with option 4 of the SYSTERM System Service, otherwise PTF install takes 
place at IPL time, with attendant delay in DPCX initialisation. The con- 
trol statements illustrated in Figure 13 will ask for installation at 
shutdown. 


SYSINFOREF with Host Prep Release 5 or laver can request an immediate IPL 
of DPCX; control statements to use this facility are shown in Figure 14. 
Take care that they are executed when no-one is using DPCX! Make sure that 
the communication phase of SYSINFOREF executes over-night. 


GENERATE SYSID(TESTZZ10) 
INSTALL SHUTD ACTION 


END 
STARTCOM SYSID(TESTZZ10) 
LIST RESPONSE (ALL) SYSID(TESTZZ10) 


Figure 13. Installing PTFs at  DPCX shutdown at the test 
system: these control statements will transmit to the 
test 8100 a request for PTF installation when all other 


GENERATE SYSID(TESTZZ10) 

INSTALL IPL ACTION 

END IPL IMMEDIATE 
STARTCOM SYSID(TESTZZ10) 

LIST RESPONSE (ALL) SYSID(TESTZZ10) 


Figure 14. Installing PTFs using immediate IPL at the test 
system: these control statements will transmit a 
request for PTF installation at IPL to the test 8100 and 
then cause the IPL (SYSINFOREF Release 5.0). 
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Step 6: Check the status of the PTF installation: Which ever method is 
adopted to effect the installation, control statements such as those in 
Figure 15 should be executed subsequently to determine the results of the 
installation. 


° The PTF installation messages are a blow-by-blow account of what actu- 
ally took place. 


e The RETRIEVE PTF VERIFY causes the status of each PTF to be tested by 
a comparison of the verify and replace data in the PTF with the actual 
target data in the DPCX system. 


The results of this should be checked against those expected as appended 
to the Memo to Users distributed with the PTF diskette; this lists PTFs 
whose status is anticipated to be other than installed. Hopefully, the 
only other PTFs not appearing as installed will be those in a privi- 
lege/hold status, usually for national language features. This may be 
ascertained from the information produced by the following: 


° The RETRIEVE PTF STATUS statement lists the status of each PTF as 
recorded in the PTF data set: whether or not installed, where it came 
from, whether held and what requisites it has. 


This latter listing should be retained for future reference, as it records 
all the PTFs at the DPCX system. 


GENERATE SYSID(TESTZZ10) 

RETRIEVE PTF MSG 

RETRIEVE PTF VERIFY 
RETRIEVE PTF STATUS 

END 

STARTCOM SYSID(TESTZZ10) 

LIST RESPONSE (ALL) SYSID(TESTZZ10) 


& 
& 
& 
& 
& 
& 
& 


Figure 15. Determining the results of test system PTF 
installation: these control statements retrieve the 
messages generated by PTF installation from the test 
DPCX system, and test and list the status of PTFs there, 
and print the results from the response file. 
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Steps 7 and 8: Test the system and perform any necessary regression: 
The test 8100 should be used sufficiently to conclude that there is no 
impact on operation. If a PTF is determined to have caused a problem, on 
the advice of the IBM Support Centre it may be removed by: 


e executing control statements such as those in Figure 16 which will 
remove PTF UC54321 


° then invoking PTF installation as in Figure 13 on page 31 or Figure 14 
on page 31 


° and retrieving the removal message as in Figure 17 


Specifying ACTION(HOLD) on the SYSPTF process prevents the PTF from being 
inadvertently re-installed. Note that a PTF cannot be deleted from the 
DPCX PTF dataset; it will remain until the next update install of a 
release of DPCX erases the contents of the PTF dataset. 


GENERATE SYSID(TESTZZ10) ; 
REMOVE PTF (UC54321) ACTION (HOLD ) ; 
END 3 


STARTCOM SYSID(TESTZZ10) 
LIST RESPONSE (ALL) SYSID(TESTZZ10) 


Figure 16. Removing an erroneous PTF: these control statements 
will request that the install process for PTF UC54321 on 
the test 8100 be reversed. 


& GENERATE SYSID(TESTZZ10) 
& RETRIEVE PTF MSG 
& END 
ES STARTCOM SYSID(TESTZZ10) 
& LIST RESPONSE (ALL) SYSID(TESTZZ10) 


Figure 17. Determining the results of test system PTF 
removal: these control statements retrieve the messages 
generated by removing a PTF from the test DPCX system. 
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Step 9: Send the PTFs to the production DPCX systems: Again generation 
is required for level RO2M02, feature 6001F and feature DOSF21. By 
restricting generation to class 1, transmitting the PTFs a second time to 
the test 8100 (class 900) is avoided. Although there may be 8100s at the 
lower software level included in class 1, nothing will be sent to them as 
nothing was generated for their software levels or features. The sample 
control statements are in Figure 18. 


The diskette identification is used again to transmit only the new PTFs, 
and ACTION(CINSTALL) is specified in order to be able to request installa- 
tion of only the PTFs which are being sent. The (10) operand of the START- 
COM indicates the number of transmissions which will be run concurrently 
by SYSINFOREF as subtasks. Increasing this up to the number of production 
systems will reduce the elapsed time of the job, but it may be necessary 
to keep it lower to contain the traffic loading on network resources. 


& GENERATE LEVELCRO2M02 ) CLASS (1) : 
& SEND PTF 

& DISKETTE (CD20023) ACTIONCINSTALL) : 
& END : 
& GENERATE FEATURE (6001F) CLASS (1) : 
& SEND PTF 

& DISKETTE (CD20023) ACTIONC INSTALL) ; 
& END : 
& GENERATE FEATURE (DOSF21) CLASS (1) ; 
& SEND PTF 

& DISKETTE (CD20023) ACTIONCINSTALL) : 
& END | : 
-& STARTCOM(10) CLASS(1) : 
& LIST RESPONSE (ALL) : 


Figure 18. Sending PTFs to the production systems: these control 
statements will transmit the new PTFs to the production 
DPCX systems. 
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Step 10: Hold any erroneous PTFs: If any PTFs had to be backed off the 
test system, they should be placed in a HOLD status on the production sys- 
tems before installing. The control statements in Figure 19 show how to do 
this for PTF UC54321. The UPDATE statement may instead be placed after 
the last SEND statement in Figure 18 on page 37. 


GENERATE LEVEL(RO2M02) CLASS (1) 
UPDATE PTF (UC54321) ACTION (HOLD) 
END | 

STARTCOM(10) CLASS(1) 

LIST | RESPONSE (ALL) 


Figure 19. Placing an erroneous PTF in HOLD status: these control 
statements will place PTF UC54321 in HOLD status for 
each production DPCX system to prevent its installation. 
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Step 11: Install the PTFs on the production DPCX systems.: Again the 
ACTION option causes only the new PTFs to be installed. Control state- 
ments to cause installation at DPCX shutdown are shown in Figure 20, and 
those (for SYSINFOREF with Host Prep Release 5.0 or later) to cause a DPCX 
IPL and subsequent installation in Figure 21. For installation to occur 
at DPCX shutdown, the control operator must properly close down active 
tasks and request shutdown with option 4 of the SYSTERM System Service. 


GENERATE LEVEL(RO2M02) CLASS(1) 
INSTALL SHUTD | ACTION 
END | 

STARTCOM CLASS(1) 

LIST RESPONSE (ALL) 


20. Installing PTFs at  DPCX shutdown at _— production 
systems: these control statements will transmit to the 
production DPCX systems requests for PTF installation 
when all other tasks terminate. 


& GENERATE LEVEL(RO2M02) CLASS (1) : 
& INSTALL IPL ACTION ; 
& END IPL IMMEDIATE : 
& STARTCOM CLASS (1) ; 
& LIST RESPONSE (ALL) : 


Figure 21. Installing PTFs using immediate IPL at production 
systems: these control statements will transmit to the 
production DPCX systems requests for PTF installation at 
IPL and then cause the IPL (SYSINFOREF Release 5.0). 
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Step 12: Determine the results of PTF installation: As with the test 
machine, so with the production systems, the statements in Figure 22 
should be executed later to verify the results of the installation. See 
the comments under Step 6 above for the uses to which these listings 
should be put. 


For systems at the same level, these listings should be similar, if main- 
tenance has been applied consistently across the network. 


GENERATE LEVEL(RO2M02) CLASS (1) : 
RETRIEVE PTF MSG : 
RETRIEVE PTF VERIFY : 
RETRIEVE PTF STATUS : 
END ; 
STARTCOM(10) CLASS(1) : 
LIST RESPONSE (ALL) : 


& 
& 
& 
& 
& 
& 
& 


Figure 22. Determining the results of production system PIF 
installation: these control statements retrieve the 
messages generated by PTF installation from’ the 
production DPCX systems, and test and list the status of 
PTFs there, and print the results from the response 
file. 


Network Management of System Software 43 


The preceding steps must be repeated to install the PTFs on the BySneey 
with the lower software levels. It is advisabie either to: 


e restore the squdvalent system, duinped to tape ord installing the 
higher software level, on the test system, and install first on the. 
test system. The updated system would then be saved. 


or to 


e select one of the production systems at the lower level as a pilot 
system and use it in the same fashion as the test system, installing 
the PTFs on it first. 


Eventually, when all DPCX systems are upgraded to the higher software lev- 
els, it will be possible to delete the PTFs for the earlier levels from 
the host PTF library. The control statements in Figure 23 will do that. 


& DELETE PTF LEVEL(RO2M01) 
& DELETE PTF FEATURE (6001E) 
& DELETE PTF FEATURE (DOSF20) 


Figure 23. Deleting PTFs for redundant software levels: these 
control statements delete from the host PTF library 
copies of PTFs which applied to DPCX Release 2.1 and 
features 6001E and DOSF Release 2.0. 


The procedure which has been described above will never quite be complete, 
since from time to time special instructions are supplied for the instal- 
lation of PTF diskettes. For example, both the following have occurred: 


° A requirement to run the PTF installation twice in order to install 
correctly a complicated sequence of inter-dependant PTFs. 


e A need to install one PTF before the rest of those on the diskette. 


Also, if you use a national language feature, if the Memo to Users which 
accompanies the PTF diskette indicates that a PTF applicable to your fea- 
ture is included, you will need to take it out of HOLD status and install 
it. Because it will also be flagged as privileged, the installation must 
be performed using the DPoOX SYSPTF System Service. If host communications 
are enabled so to as allow only one batch (host-initiated) session, this 
may be done via HCF, using the signon for operators 1 or 255, but all other 
users must be signed off and tasks stopped. Use option 8 of SYSPTF to ena- 
ble the PTF, and option 1 to install it. 
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3.2.3 INSTALLING CORRECTIVE SERVICE TO SYSTEM SOFTWARE 


This section suggests a procedure you may adopt to apply an individual 
PTF, which is required to fix a specific problem on a DPCX system, to DPCX 
and DOSF throughout the network. If the PTF has no adverse effect on sys- 
tem operation, installation of the PTF throughout the network is recom- 
mended, as this avoids the possibility of the problem recurring elsewhere, 
and overall ease of maintenance is enhanced by having as few as possible 
different software levels in the network. The PTF is retained on the host 
PTF library while the software level to which it applies is current any- 
where in the network. It is assumed that SYSINFOREF has been initialised 
as in "Initialising SYSINFOREF" on page 127. Examples of control state- 
ments are included - the JCL is as in Figure 61 on page 127. 


A PTF for corrective service will normally be in the form of a list of 
changes which have to be manually entered on to the host PTF library. 


The steps entailed are as follows; Figure 24 on page 46 provides a sche- 
matic representation. 


1. Use SYSINFOREF to add the PTF to the host PTF library using the sup- 
plied source information. 


2. Send the PTF to the test DPCX system®. 
3. Install the PTF on the test system. 
4. Retrieve the PTF installation messages. 


Verify the operation of the test DPCX system - if it is impacted the prob- 
lem should be referred to the IBM Support Centre. 


5. Send the PTF to the DPCX system which encountered the problem. 
6. Install the PTF on this system. 
7. Retrieve the PTF installation messages. 


Verify the operation of this 8100 - if the problem has not been resolved 
it should be referred to the IBM Support Centre. 


8. Send the PTF to the other production systems. 
9. Install the PTF on these systems. 
10. Retrieve the PTF installation messages. 


The examples assume that there are some DPCX systems in the network with 
DPCK Release 2.2, feature 6001F and DOSF Release 2.1 and it is on DOSF on 
one of these, the system whose SYSID is TEXTAD10, that a problem has been 
encountered. The test system is at this level. Furthermore, the pro- 
duction systems have been defined to the SYSINFOREF machine list as being 
in class 1 and the test 8100 as being in class 900. PTF UC12345 is to be 
installed. 


, If the problem is urgent and severely impacting the affected 8100, it 


may be preferable to send first to that machine and test the PTF 
there. 
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Figure 24, Network application of corrective service: this is a 
schematic of the processes involved in installing a 
diskette of PTF supplied by the IBM Support Centre across 
the network. 


For convenience of illustration, the sample control statements show the 
SYSINFOREF maintenance, generation, communication and response phases 
being executed consecutively within a single jobstream. As described in 
"SYSINFOREF Phases and Timing of Sessions’ on page 128, it may well be 
desirable to separate the execution of the different phases. 
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Step 1: Create the PTF on the host PTF library: The control statements 
in Figure 25 are an example. If the PTF had been for DPCX instead of DOSF, 
LEVEL(RO2M02) would have been coded in place of FEATURE(DOSF21). The PTF 
number, source statements and the CHECKSUM value will be supplied by the 
IBM Support Centre. Pre-requisite and co-requisite information might 
also need to be coded on the control statement. 


& ADD PTF (UC12345) FEATURE (DOSF21) 
& CHECKSUM(cccc) 


1 nn mmmm bbbb 
2 dd ccccecce rrrrrrrr 
2 ECCCCCCE TLYVErrrr 


‘LIST —sO PT F(UC12345) FEATURE (DOSF21) 
~ TEXT ; 


Figure 25. Adding a PTF to the host PTF library with source 
statements: these control statements will add PTF 
UC12345 to the host PTF library from source statements 
supplied by the IBM Support Centre. 


If the PTF had a pre-requisite, ensure that this is either installed on 
DPCX or available on the SYSINFOREF library; in the’ latter case the 
pre-requisite PTF will be transmitted and installed along with the other. 
If the host PTF library was listed as in Figure 10 on page 27 when preven- 
tive service was last applied, and if PTF listings were retrieved from the 
network as in Figure 22 on page 43, then this information may already be 
available. If not, then the control statements in Figure 26 show how to 
elicit it for pre-requisite PTF UC01234. If a pre-requisite PTF is miss- 
ing, DPCX does not issue a warning message and you will be left wondering 
why your PTF would not install. 


GENERATE FEATURE (DOSF21) 

RETRIEVE PTF (UC01234) STATUS 

END 

STARTCOM(10) NETWORK 

LIST RESPONSE (ALL) 

LIST PTF (UC01234) FEATURE (DOSF21) 


MMS OMe 


Figure 26. Determining the status of a pre-requisite PTF: these 
control statements will show if a pre-requisite PTF is 
installed on each DPCX system in the network with the 
given software level, and whether it is present on the 
host library. 
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Steps 2, 3 and 4: Send the PTF to the test DPCX system and install it: 
Note that the SEND PTF request must be generated by the appropriate level 
or feature’. The control statements shown in Figure 27 will do this. 
(Prior to Host Prep R5, if generation is performed for SYSID(TESTZZ10) the 
PTF would only be sent if it applied to DPCX level RO2M02.) 


Specify ACTIONCINSTALL) and INSTALL ACTION in order to request installa- 
tion of only the PTF which has just been transmitted. The PTF will be 
installed at the next DPCX IPL. 


GENERATE FEATURE (DOSF21) : 
SEND PTF (UC12345) ACTION C(CINSTALL) : 
INSTALL IPL ACTION ; 
END ; 
STARTCOM SYSID(TESTZZ10) ; 
LIST RESPONSE (ALL) SYSID(TESTZZ10) : 


& 
& 
& 
& 
& 
& 


Figure 27. Sending a PTF to the test system: these control 
statements will transmit PTF UC12345, created at the 
host, to the test 8100. 


Once the test system has been [PLed, the control statements shown in 
Figure 17 on page 35 should be executed to retrieve the PTF installation 
messages. 


’ For SYSINFOREF with Host Prep Release 5.0, it is possible to generate 
by SYSID and pick up the feature PTF. 
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(10) 


OTHER 
PRODUCTION 
81008 


FAILING 
PRODUCTION |< 
8100 


(7) 
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Steps 5, 6 and 7: If it works, send the PTF to the affected system: The 
operation of the test DPCX system should be evaluated - if the PTF causes 
no adverse effect, it may be sent to DPCX system TEXTAD10 which first 
encountered the problem. If the problem was reproducible on the test sys- 
tem, it may be possible to tell at this point if the PTF will fix it. 


The PTF is sent to the production DPCX system TEXTAD10 and installed. The 
same control statements as previously shown in Figure 27 on page 51 are 
used, the only change being on the STARTCOM statement to change 
SYSID(TESTZZ10) to SYSID(TEXTAD10). The PTF will be installed at the next 
DPCX IPL. 


After IPLing this system, execute the control statements in Figure 17 on 


page 35 to retrieve the PTF installation messages; the SYSID value should 
be TEXTAD10. 
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PTF STATEMENTS 
SUPPLIED BY IBM 
SUPPORT CENTRE 


SYS INFOREF 
PTF 
LIBRARY 


(2) (8) 


INSTALL ————(9) 


SYSINFOREF |< (10) 
RESPONSE 


FILE 


OTHER 
PRODUCTION 
81008 


FAILING 
PRODUCTION |< 
8100 


(7) 
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Steps 8, 9 and 10: If successfull, send the PTF to the other systems: If 
the PTF is verified to have fixed the problem, it should be sent to the 
other 8100s in the network at the same software level. The control state- 
ments in Figure 28 will do this. Note that they will try and send the PTF 
again to the system with SYSID of TEXTAD10. The request for this machine 
will fail, and nothing will be installed on this system. 


GENERATE FEATURE (DOSF21) 
PTF (UC12345) ACTION CINSTALL) 
IPL ACTION 


STARTCOM CLASS (1) 
LIST RESPONSE (ALL) 


& 
& 
& 
& 
& 
& 


28. Sending a PTF to the other production systems: these 
control statements will transmit PTF UC12345, created at 
the host, to other 8100s in the network at the specified 
software level. 


Messages from the installation process should subsequently be retrieved 
with the control statements in Figure 29. 


GENERATE FEATURE (DOSF21) CLASS (1) 
RETRIEVE PTF MSG 

END 

STARTCOM CLASS (1) 

LIST RESPONSE (ALL) 


29. Retrieving PTF installation messages from the other 
8100s: these control statements retrieve the messages 
generated by PTF installation from the production DPCX 
systems and print them from the response file. 


If the PTF in fact had an adverse effect on a system, or did not fix the 
problem, it can be removed using control statements such as those in 
Figure 16 on page 35, referencing the appropriate 8100. 


3.2.4 INSTALLING PTFS AFTER AN INITIAL OR UPDATE INSTALL 


When a new DPCX/DOSF system is installed, you will want to ensure that the 
software is at the same level as that on the currently installed systems. 
Also, if DPCX and DOSF are update installed on an 8100 to a new release, 
the contents of the DPCX PTF dataset are purged. You will need to send any 
PTFs, now applicable to the new release, to the 8100. Often you will 
receive a new PTF diskette with a new release of DPCX and DOSF. 


The procedure to follow is conceptually the same as that in "Installing 


Preventive Service to System Software’ on page 21, but there are some dif- 
ferences. The following cases are considered: 
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1. A new 8100 has been installed at the same level of DOSF and DPCX as 
currently in use at other systems in the network. It is desired to 
install those PTFs currently installed on other 8100s. : 


2. Some 8100s have been update installed to a new release of DPCX and 
DOSF. It is desired to install those PTFs which apply to the new level 
of the system software. 


Case 1 - A new 8100 with the current release of DPCX and DOSF: Follow 
steps 9 through 12 of "Installing Preventive Service to System Software" 
on page 21: 


Step 9: The new system requires all PTFs, not just those from the latest 
diskette. Figure 30 contains appropriate control statements; TEXTAK10 is 
the batch logical unit of the new 8100. 


GENERATE LEVEL(RO2M02) 
SEND PTF ACTION C INSTALL) 
END 
GENERATE FEATURE (6001F) 
. PIF ACTIONCINSTALL) 


GENERATE FEATURE (DOSF21) 

SEND PTF ACTION( INSTALL) 
END 

STARTCOM SYSID(TEXTAK10) 

LIST RESPONSE (ALL) SYSID(TEXTAK10) 


& 
& 
& 
& 
& 
& 
& 
& 
& 
& 
& 


we we we we we we we we we we we 


Figure 30. Sending PTFs to a new 8100: these control statements 
will transmit all applicable PTFs to anew DPCX/DOSF 
system. 


Step 10: Don't forget to hold any PTFs which you have not installed on or 
removed from other systems. Change the STARTCOM in Figure 19 on page 39 to 
specify SYSID(TEXTAK10) instead of CLASS(1). 


Steps 11 and 12: Are the same as in "Installing Preventive Service to 
System Software'’ on page 21, the only alteration being to change the 
STARTCOM in Figure 20 or Figure 21 on page 41 and in Figure 22 on page 43 
to specify SYSID(TEXTAK10) instead of CLASS(1). 


Case 2 - Current 8100s with a new release of DPCX and DOSF: Follow 
steps 1 through 12 of "Installing Preventive Service to System Software" 
on page 21. It is assumed that the new level of code will be installed 
first on the test 8100 and that the PTFs will be sent first to this system. 
Don't forget to retain a tape copy of the DPCX/DOSF system from the test 
8100 at the existing level for as long as this release is current anywhere 
in the network. The software levels in figures referenced in the steps 
cited below will of course need to be changed to reflect the new software 
release. 


Steps 1, 2 and 3: If there is a new PTF diskette supplied with the new 
software release, you will need to retrieve the latest PTF diskette to the 
host and copy applicable PTFs into the host PTF library. | 


Step 4: Be sure to send all applicable PTFs: omit the DISKETTE() parame- 
ter from the SEND PTF statement in Figure 12 on page 29. 
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Steps 5 through 8: These are performed exactly as in "Installing Preven- 
tive Service to System Software." 


Step 9: Be sure to send all applicable PTFs: omit the DISKETTE() parame- 
ter from the SEND PTF statement in Figure 18. 


Steps 10, 11 and 12: Are performed exactly as in "Installing Preventive 
Service to System Software’ on page 21. 


3.2.5 USING HCF WITH THE SYSPTF SYSTEM SERVICE 


As mentioned in "Overview of DPCX/DOSF PTF Handling" on page 134, the DPCX 
System Service SYSPTF may also be used for processing PTFs. All of its 
functions are available at the host using Host Command Facility; but as in 
order to install PTFs all other tasks must be stopped and only one 
host-initiated session enabled, its use for this purpose during office 
hours is somewhat impracticable. Moreover, either the control operator or 
service representative signon must be used to be able to invoke SYSPTF, 
with possible operational implications. However, HCF may be useful for 
the following purposes (which are not constrained by the need to be the 
only task active): 


. Listing or verifying the status of PTFs installed on a particular 
8100, especially in order to browse, for instance, a chain of 
pre-requisite PTFs. This function should not often be needed if 
records are kept as suggested in "Recording Changes to System Soft- 
ware,’ anda listing of PTF status retrieved after each application of 
preventive maintenance. 


e Enabling or disabling a PTF on production 8100s, the SYSINFOREF con- 
trol statements for which were illustrated in Figure 19 on page 39. 
Note, though, that the more 8100s there are in the network, the more 
efficient it is to use SYSINFOREF. 


There is also one instance in which SYSPTF must be used, and that is: 
e To install a privileged PTF. Privileged PTFs are only installed on 
instruction from the IBM Support Centre, but if it is necessary to 


install one it may be done using HCF (with all other tasks stopped, 
operators signed off and only one host-initiated session enabled). 


3.3 RECORDING CHANGES TO SYSTEM SOFTWARE 


A log should be kept for each DPCXK system of software updates installed. A 
sample form for this can be found in "Sample Forms" on page 169. In use it 
might resemble the example in Figure 31 on page 58. 
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8100 SYS B RALEIGH TEXTAB10 


System: -sS<-sesero= at. SSrseras Baten. LU @+Sssesss5e= 
Product Update level, | Date 
Identifier Fix Package Installed 
or PTF id. 

DPCX 5761-DS1 RELEASE 2.2 O8AUG82 
DPCX #6001 5761-DS1 LEVEL F O8AUG82 

DOSF 5761-XR1 RELEASE 2.1 O8AUG82 
DPCX / #6001 / DOSF FIX PACKAGE 23 12AUG82 
DPCX #6001 F PTF UC12345 19SEP82 


Figure 31. Recording system software updates: this is how a log 


could be kept of installation of service to system 
software on a DPCX/DOSF system. 


58 DPCX/DOSF Network Management 


4.0 NETWORK MANAGEMENT OF APPLICATION SOFTWARE 


There are four techniques available for software management of DPCX appli- 
cation software. They are appropriate both for installing initial and sub- 
sequent versions of IBM and user programs, and for managing PTFs for IBM 
programs. They are: 


1. SSS (Subsystem Support Services) 
2. Host Prep BDES (Batch Data Exchange, 5735-XR3) 


3. Host Prep SYSINFOREF (Subsystem Information Retrieval Facility, 
5735-XR3) 


4. DSX (Distributed Systems Executive, 5748-XXG or 5668-986) 


To use any of these products to manage DPCX application software, function 
such as is contained in Host Prep PVS (Program Validation Services, 
5735-XR3) is pre-requisite. 


Use of BDES requires manual intervention at the distributed system sites. 
SSS is the original network management tool; both SYSINFOREF and DSX are 
more efficient and are to be preferred. Of the latter two products the 
more appropriate technique for management of DPCX application software 
depends on a few simple factors: 


e Is the number of DPCX systems more, or likely to become more, than 
about twelve? 


e Is DSX already installed (perhaps for use with 8100/DPPX)? 


° Are data applications to run under DPCX that require the host system 
to update DPCX datasets? 


e Do you wish to use the Network Installation Management (NIM) capabili- 
ty of DPCX release 3? 


If the answer to any of these questions is ‘'yes', then DSX is the pre- 
ferred network management tool. DSX maintains an inventory of the soft- 
ware installed at each distributed system, and has better reporting 
capabilities and ease-of-use features. DSX will also be needed if host 
update of DPCX datasets is required, or in order to use NIM. 


If, however, the answer to all these questions is 'no', then SYSINFOREF 
can do the job and avoid the complexity of installing another product. 
SYSINFOREF will probably be wanted already to maintain system software. 


4.1 OVERVIEW OF DPCX APPLICATION SOFTWARE INSTALLATION 


Application programs and panels in source form have to be assembled using 
the macros supplied with the Host Prep product. The assembler object mod- 
ule is supplied as input to Host Prep PVS, and, using the READY control 
statement, output is created on the BQBLIBI® dataset. DSCBs are defined 
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to PVS using control statements and likewise written to BQBLIBI® .SYSINFO- 
REF (or DSX) uses this dataset to update its library. This flow is illus- 
trated in Figure 32 on page 61. 


The SYSINFOREF library is a repository for all application entities (pro- 
grams, panels and DSCBs) to be sent to DPCX/DOSF systems. Objects are 
keyed on the library by the number of the program, panel or DSCB; not by, 
for instance, program name. Different versions and levels, assigned by 
the PVS READY control statement, are supported by SYSINFOREF. Care should 
be taken to 


° Retain in the SYSINFOREF library each version/level of each entity, 
either currently in use or potentially needed for fall-back, on any 
8100 in the network, 


and conversely 


° Not to delete anything from the SYSINFOREF library until it is no lon- 
ger in use, or possibly going to be needed, anywhere. 


4.2 USING SYSINFOREF VERSIONS AND LEVELS FOR APPLICATIONS 


Careful use of version and level is the key to easy software management. 
Conceptually, application entities that come from the same place and 
should be installed together (for example, all progrene on a PTF tape) 
should have the same version and level numbers. 

For IBM-supplied products: 


: Use the version number in some meaningful way to represent the release 
number of the product 


: Set the level number to 0 when installing a new release 


° Increment the level number to refer to successive applications of pre- 
ventative maintenance (for example, PTF tapes) 


° For application of corrective service, such as APAR fixes, use level 
numbers greater than 50. 


Some exceptions will have to be made: 

: DSCBs for a RSDS and its indices are keyed under the same name. 
Assign a version, and use level 0 for the base RSDS, level 1 for index 
1 up to level 8 for index 8. Fortunately DSCBs are not likely to be 
altered by the application of software maintenance. 

: An application (DISOSS is an example) may have one or more programs or 
panels customised to specific controllers. In this case, use the lev- 
el number to denote copies for different DPCX/DOSF systems. 

For User-coded Applications: 

e set the version to 1 and the level to 0 initially 


In Host Prep Release 5.0, PVS can write its output directly to the 
SYSINFOREF or BDES library. 
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DMS/DPCX |< DMS 


MSL 
ee 
V 
program 
and > system < SYS1. 
panel assembler TNDMAC 


source 


.& LOAD 
.& DEFINE DS 
.& READY 


program 
object 
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.& COPY 
MEMBERS 


BQBLIBI 


V 


BHDSSIL 


Figure 32. Application software generation: this summarises the 
flow of application entities from source statements to 
the SYSINFOREF library. 


If the function of the application is enhanced, changing and adding a 
lot of modules, make this a new version: change the version number and 
set the level number to 0 


When errors are corrected in modules, increment the level numbers of 
the new modules 


If the application needs to differ from 8100 to 8100, see if this can 
be achieved with common programs driven, for instance, by a customised 
control record in a dataset. If this is not possible, try to assign 
the slightly different programs different program numbers. Maintain- 
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ing functionally different versions of the same application in the 
SYSINFOREF library is likely to lead to confusion. 


4.3 MAINTAINING APPLICATION SOFTWARE 


This section suggests a procedure to adopt in order to apply service to 
application software across the network. There is no difference in the 
technique employed whether preventative or corrective service is being 
applied, or, indeed, if the product is being installed for the first time; 
though if a corrective service PTF is being applied, you may want to 
install the changed module on the DPCX system with the problem before 
releasing it to the rest of the network. 


This procedure is designed to retain a central library of all levels of 
applications current anywhere in the network. It assumes that SYSINFOREF 
has been initialised as described in "Initialising SYSINFOREF'" on page 
127. Examples of control statements are included. Use the same JCL as 
that in Figure 61 on page 127. 


The steps are as follows. They are illustrated in Figure 33 on page 63. 


1. Load the application entities with PVS, write them to BQBLIBI® and 
copy them to the SYSINFOREF BHDSSIL dataset. 


2. Send the modules to the test DPCX System. 


3. Verify the operation of this 8100. If the new code has any adverse 
effect on the test system, some or all might have to be regressed. 
This is achieved by re-sending the previous version. 


4. If Step 3 is successful, send the modules to production DPCX systems. 


The examples assume that a PTF tape has been received for DISOSS/8100°*°. 
The tape is identified as PTF8303 and it is the second tape that you have 
received. It contains replacement modules for five FPs and four panels, in 
assembler object code which you have loaded into the OS partitioned data- 
set named 'DISOSS.PTF2'. The production systems have been defined to the 
SYSINFOREF machine list as being in class 1, and the test 8100 as being in 
a separate class, 900. (See "SYSINFOREF Classes" on page 126 for a dis- 
cussion of SYSINFOREF classes. ) 


For convenience of illustration, the sample control statements show the 
SYSINFOREF maintenance, generation, communication and response phases 
being executed consecutively within a single jobstream. As described in 
"SYSINFOREF Phases and Timing of Sessions on page 128, it may well be 
desirable to separate the execution of the different phases. 


In Host Prep release 5.0, PVS can write directly to the BHDSSIL data- 
set. 

This example is fictitious, for the purpose of illustration only. It 
should not be construed that any such PTF tape as PTF8303 will be pro- 
duced for DISOSS/8100. 


10 
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ASSEMBLED 
OBJECT 
CODE 


PVS 
BQBLIBI 


SYS INFOREF 
BHDSSIL 


(2) (4) 


TEST < 


PRODUCTION 
81008 


Figure 33. Network installation of service to application 
software: this is a schematic of the processes involved 
in installing application code across the network. 
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ASSEMBLED 
OBJECT 
CODE 


PVS 
BQBLIBI 


SYS INFOREF 
BHDSSIL 


(2) (4) 


TEST < 


PRODUCTION 
81008 
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Step 1: Load the modules on the SYSINFOREF library: The replacement 
modules must be taken from the library to which they were loaded from the 
PTF tape, and copied to the SYSINFOREF BHDSSIL dataset. For Host Prep 
releases prior to 5.0, the PVS job shown in Figure 34 followed by the SYS- 
INFOREF control statements in Figure 35 on page 66 will achieve this, but 
for release 5.0 or later the PVS job illustrated in Figure 36 on page 67 
does this in one step. Note the assignment of version 1 level 2 to this 
PTF on the PVS READY statements. 


//PVS JOB HOSTPREP 
//READY | EXEC PGM=BQIPVS 
//STEPCAT DD DISP=SHR , DSN=vsam_user_catalog (if needed) 


//STEPLIB DD DISP=SHR , DSN=Host_Prep_load_library (if needed) 

//BQBLIBI DD DISP=SHR , DSN=BQBLIBI 

//SYSLIN DD DISP=SHR , DSN=DISOSS. PTF2(DSVFO0005 ) 
DD DISP=SHR , DSN=DISOSS. PTF2(DSVF0008) 
DD DISP=SHR , DSN=DISOSS.PTF2(DSVF0017) 
DD DISP=SHR , DSN=DISOSS. PTF2(DSVF0018) 
DD DISP=SHR ,DSN=DISOSS.PTF2(DSVF0053) 
DD DISP=SHR , DSN=DISOSS.PTF2(DSVP7715) 
DD DISP=SHR , DSN=DISOSS.PTF2(DSVP7718) 
DD DISP=SHR , DSN=DISOSS .PTF2(DSVP7745) 
DD DISP=SHR , DSN=DISOSS . PTF2(DSVP7794) 

SYSPRINT DD SYSOUT=A 

SYSIN DD * 

DEFINE CONTROLS NOPGMR; 

LOAD PROGRAM INPUT(DISK) ; 

READY PROGRAM(7805) VERSION(1) LEVEL(2); 

LOAD PROGRAM INPUT(DISK) ; 

READY PROGRAM( 7808) VERSION(1) LEVEL(2); 

LOAD PROGRAM INPUT(DISK) ; 

READY PROGRAM(7816) VERSION(1) LEVEL(2); 

LOAD PROGRAM INPUT(DISK) ; 

READY PROGRAM(7817) VERSION(1) LEVEL(2); 

LOAD PROGRAM INPUT(DISK) ; 

READY PROGRAM(7828) VERSION(1) LEVEL(2); 

LOAD PANEL INPUT(CDISK) ; 

READY PANEL(7715) VERSION(1) LEVEL(2); 

LOAD PANEL INPUT(DISK); 

READY PANEL(7718) VERSION(1) LEVEL(2); 

LOAD PANEL INPUT(DISK); 

READY PANEL(7745) VERSION(1) LEVEL(2); 

LOAD PANEL INPUT(DISK) ; 

READY PANEL(7794) VERSION(1) LEVEL(2); 


/ 
/ 
/ 
/ 
/ 
/ 
/ 
/ 
/ 
/ 
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/ cy 
// 
Figure 34. Loading application modules and readying on 

BQBLIBI: this job uses Host Prep PVS to load 


application modules and write them to the BQBLIBI 
dataset, assigning version 1 level 2. 
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& COPY MEMBER | : 
FP7805,1,2 
FP7808,1,2 
FP7816,1,2 
FP7817,1,2 
FP7828,1,2 
PN7715,1,2 
PN7718,1,2 
PN7745,1,2 
PN7794,1,2 


Figure 35. Copying application modules to BHDSSIL: these control 


statements cause SYSINFOREF to copy application modules 
from the BQBLIBI dataset to the BHDSSIL library. 
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//PVS JOB HOSTPREP 

/ /READY EXEC PGM=BQIPVS 

//STEPCAT DD DISP=SHR , DSN=vsam_user_catalog (if needed) 

//STEPLIB DD DISP=SHR , DSN=Host_Prep_load_library (if needed) 

//BQISSIL DD DISP=SHR , DSN=BHDSSIL 

//SYSLIN DD DISP=SHR , DSN=DISOSS . PTF2 (DSVF0005 ) 
DD DISP=SHR , DSN=DISOSS . PTF2 (DSVF0008 ) 
DD DISP=SHR , DSN=DISOSS.PTF2 (DSVF0017) 
DD DISP=SHR , DSN=DISOSS. PTF2 (DSVF0018) 
DD DISP=SHR , DSN=DISOSS . PTF2 (DSVF0053) 
DD DISP=SHR,DSN=DISOSS.PTF2(DSVP7715) 
DD DISP=SHR , DSN=DISOSS .PTF2 (DSVP7718) 
DD DISP=SHR , DSN=DISOSS .PTF2(DSVP7745) 
DD DISP=SHR , DSN=DISOSS. PTF2(DSVP7794) 

SYSPRINT DD SYSOUT=A 

SYSIN DD ¥ 

DEFINE CONTROLS NOPGMR; 

READY USING BQISSIL; 

LOAD PROGRAM INPUT(DISK) NOPASS3; 

READY PROGRAM(7805) VERSION(1) LEVEL(2); 

LOAD PROGRAM INPUT(DISK) NOPASS3; 

READY PROGRAM(7808) VERSION(1) LEVEL(2); 

LOAD PROGRAM INPUT(DISK) NOPASS3; 

READY PROGRAM(7816) VERSION(1) LEVEL(2); 

LOAD PROGRAM INPUT(DISK) NOPASS3; 

READY PROGRAM(7817) VERSION(1) LEVEL(2); 

LOAD PROGRAM INPUT(DISK) NOPASS3; 

READY PROGRAM(7828) VERSION(1) LEVEL(2); 

LOAD PANEL INPUT(CDISK) ; 

READY PANEL(7715) VERSION(1) LEVEL(2); 

LOAD PANEL INPUT(CDISK); 

READY PANEL(7718) VERSION(1) LEVEL(2); 

LOAD PANEL INPUT(DISK); 

READY PANEL(7745) VERSION(1) LEVEL(2); 

LOAD PANEL INPUT(CDISK); 

READY PANEL(7794) VERSION(1) LEVEL(2); 
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Figure 36. Loading application modules and readying on 
BHDSSIL: this job uses Host Prep PVS Release 5.0 to 
load application modules and write then to the BHDSSIL 
dataset, assigning Version 1 Level 2. 
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ASSEMBLED 
OBJECT 
CODE 


PVS 
BQBLIBI 


SYSINFOREF 
BHDSSIL 


(4) 


V — G3) 


TEST < 


PRODUCTION 
81008 
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Step 2: Send the modules to the test DPCX system: The control state- 
ments to do this are illustrated in Figure 37. REPLACE is specified with 
SEND AMEMBER to cause the previous version to be overwritten at the 8100. 


Note that to transmit application modules to an 8100, the system must be 
quiesced such that only host communication is running with just one 
host-initiated session enabled, and no users (including the control oper- 
ator) are signed on. 


& GENERATE SYSID(TESTZZ10) 


& SEND 


FP7805,1,2 
FP7808,1,2 
FP7816,1,2 
FP7817,1,2 
FP7828,1,2 
PN7715,1,2 
PN7718,1,2 
PN7745,1,2 
PN7794,1,2 
& END 


AMEMBER REPLACE 


& STARTCOM SYSID(TESTZZ10) 


& LIST 


Figure 37. 


RESPONSE (ALL) SYSID(TESTZZ10) 


Sending application modules to the test 8100: these 
control statements cause SYSINFOREF to transmit 
application modules from the BHDSSIL library to the test 
8100. 
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ASSEMBLED 
OBJECT 
CODE 


PVS | 
BQBLIBI 


SYS INFOREF 
BHDSSIL 


(2) (4) 


V (3) 


TEST | < 


PRODUCTION 
81008 
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Step 3: Test the new software and perform any regression needed: The 
test 8100 should be used until you are satisfied that the modules replaced 
by the PTF have no adverse effect on its operation. Should some or all 
modules need to be regressed, this is achieved by listing the contents of 
the BHDSSIL to establish what versions of each module exist - Figure 38 
shows how this is done, and then determining, from the application soft- 
ware change log, which version was current at the test 8100. (The applica- 
tion software change log is described in "Recording Software Changes to 
Application Software" on page 74.) The previous version of each affected 
module is transmitted using the same control statements as those in 
Figure 37 on page 69, with the versions and levels altered as appropriate. 


& LIST MEMBER ALL ; 


Figure 38. Listing modules on the BHDSSIL library: this control 
statements causes SYSINFOREF to list all versions and 
levels of all application entities on its BHDSSIL 
library. 
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BQBLIBI 


SYS INFOREF 
BHDSSIL 
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PRODUCTION 
81008 


72 DPCX/DOSF Network Management 


Step 4: Send the modules to the production DPCX systems: Figure 39 


contains the control statements for this. 


Note that to transmit application modules to an 8100, the system must be 
quiesced such that only host communication is running with just one 
host-initiated session enabled, and no users (including the control oper- 
ator) are signed on. 


& GENERATE NETWORK 

& SEND AMEMBER REPLACE 
FP7805,1,2 

FP7808,1,2 

FP7816,1,2 

FP7817,1,2 

FP7828,1,2 

PN7715,1,2 

PN7718,1,2 

PN7745,1,2 

PN7794,1,2 

& END 

& STARTCOM CLASS(1) 

E> LIST RESPONSE (ALL) 


Figure 39. Sending application modules to the production 
8100s: these control statements cause SYSINFOREF to 
transmit the application modules from the BHDSSIL 
library to production DPCX systems. 


4.3.1 PROGRAMS DISTRIBUTED ON DISKETTE 


some IBM products, typically Field Developed Programs, are distributed on 
BDES format diskettes. To install such products across the network you 
have two options: 


e Take or send the diskettes to each 8100 site in turn and install the 
product with the DPCX SYSBDISK system service. 


° Read the BDES data-stream with a user program and construct a BQBLIBI 
dataset from it, which can be input to SYSINFOREF. You may distribute 
the modules across the network as described above. 


A program to copy the BDES data-stream is not difficult to write; the data 
formats are described in full detail in licensed documentation which may 
be ordered with the Host Prep product. A sample written in PL/1 is to be 
found in "Program to Copy a BDES Tape back to BQBLIBI" on page 137. 


If a diskette reader is available at the host system, the BDES diskette 
may be read directly by the program; if not, two alternatives exist: 


° Convert the diskette to tape with an IBM 3747 or similar device. 
: If you have the DPCX Program and Panel Dataset Maintenance Utility 


field developed program, 5798-DHX, installed on the test 8100, you may 
install the BDES diskette there, and using the utility unload its con- © 
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stituent panels and datasets to tape. This tape, which is in BDES for- 
mat, becomes the input to the sample program. 


If you adopt the latter method, be aware that the utility does not unload 


DSCBs, but these may easily be keyed into PVS (DEFINE DSCB and READY DSCB) 
and generated onto BQBLIBI that way. 


4.4 RECORDING SOFTWARE CHANGES TO APPLICATION SOFTWARE 


To manage the software in the network, it is necessary to know: 


e From what sources the various versions and levels in the SYSINFOREF 
library came. SYSINFOREF will report when they were loaded. 


e Which version and level of which applications are on a given 8100, and 
when it was installed. , 


A log should be kept for each of these purposes; sample forms are in 
appendix "Sample Forms" on page 169. In use, in the context of the example 
above, such forms might resemble Figure 40 and Figure 41 on page 75. 


Product or Product, PIF or SYS INFOREF 
Module Identifier Apar Level Version Level 


DISOSS-8100 5668-955 RELEASE 1.0 


Figure 40. Recording SYSINFOREF versions and levels: this is how a 
log could be kept of the version and level numbers 
assigned to application entities when they are loaded on 
the SYSINFOREF library. 
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8100 SYS B RALEIGH TEXTAB10 
Batch LU 


Product or SYS INFOREF 
Module Identifier Version Level Installed 


DISOSS V2 15DEC82 


Figure 41. Recording application software installation: this is 
how a log may be kept of the installation of application 
software on a DPCX/DOSF system. 
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PART 2: CONFIGURATION MANAGEMENT 


This part of the manual is intended to be read by network administrators 
and systems programmers responsible for the installation of 8100 
DPCX/DOSF systems. 
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9.0 INTRODUCTION TO CONFIGURATION MANAGEMENT 


Configuration management is not an end in itself, but it is a necessary 
pre-requisite to problem management and to the usability of the DPCX/DOSF 
systems by the operators. It is treated as a separate topic because the 
time to think about configuration management is at installation and subse- 
quently when systems are changed, not when systems are already operating 
in production and problems have occurred. 


The essence of configuration management is to have at your finger-tips the 
necessary information concerning the shape of each DPCX system, both in 
hardware and software terms, so as to be able to answer queries and 
resolve problems tl.at arise. This data also becomes of vital importance 
should catastrophic hardware or software errors or external physical dam- 
age ever result in the loss of an entire DPCX/DOSF system. Good configura- 
tion management can enable an operational system to be created again more 
rapidly than is otherwise possible. 


This part of the manual is divided into two further chapters: 

e "Configuration Information that Should Be Recorded" on page 81 con- 
siders the data concerning DPCX systems which needs to be retained, 
and how the values may be set on the 8100. 

¢ "Planning for Disaster Recovery" on page 93 investigates how a system 


may be re-created if the need arises, and what precautions should be 
taken against such an eventuality. 
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6.0 CONFIGURATION INFORMATION THAT SHOULD BE RECORDED 


The purpose of this chapter is to assist in identifying the information 
that needs to be recorded, and to this end sample forms are referenced on 
which data can be manually recorded. There are various software products 
which will act as filing systems for this information, but it has to be 
manually supplied to all of them. One of these products, Informa- 
tion/Management, is described briefly in "Overview of the Informa- 
tion/Management Program Product" on page 90 at the end of this chapter. 


Where the data is used to configure DPCX by the use of commands, this 
information can be entered in the form of a DPCX PROC at the host, and sent 
to DPCX. The host library where the PROC has been placed may then be list- 
ed to obtain current configuration documentation. 


Suggestions for recording configuration information are included for the 
following: 


° System definitions (system parameters established with the DPCX 
DEFINE command) in "Establishing System Values" on page 83. 


* Operator definitions in "Establishing Operator Profiles" on page 85. 


* Host tables (SSCP, batch and LU/PGMID) in "Establishing SYSHOST Val- 
ues" on page 86. 


e SYSCONFG parameters in "Establishing SYSCONFG Values" on page 86. 
¢ SYSIMOD parameters in "Establishing SYSIMOD Values" on page 87. 


¢ RJE signon parameters and FCBs in "Establishing SYSRJE Values" on page 
88. 


¢  DOSF system values in "Establishing DOSF Values" on page 88. 

¢ DOSF queues in "Establishing DOSF Queue Definitions" on page 88. 

¢ DTF sessions in "Establishing DTF Session Definitions" on page 88. 
¢ Loop maps in "Establishing the Layout of Loops" on page 89. 


° Network terminal data in "Establishing Terminal Addresses and Setup 
Options’ on page 89. 


* Network resource names in "Establishing Network Resource Information" 
on page 90. 


6.1 DISTRIBUTING PROCS FROM A HOST TO DPCX SYSTEMS 


The technique recommended for managing PROCs is to maintain them in a par- 
titioned data set on an OS/VS host or a source statement library on a 
DOS/VSE host, and to transmit them to DPCX using RJE. The examples that 
follow all assume this method of operation. 


If your installation does not wish to use RJE, the following alternatives 
exist: 
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° If DSX is employed for network management, you may prefer to use it to 
handle PROCs. They may be created on the DSX library as CLISTs, and 
distributed with DSX. (This requires the SPE for DSX Version 1 con- 
tained in PTF UP90061.) An example of this technique may be found in 
Figure 2 on page 12 under "DPCX/DOSF Initial Installation’ on page 8. 


e PROCs may be created as documents on the test 8100, archived to the 
host with DISOSS and retrieved to the production systems where they 
can be made into PROCs with the CPROC command. This requires inter- 
vention on each production 8100, though HCF could be employed to per- 
form the retrieval from a host attached terminal. | 


° If the installation employs DIF, the PROCs could be created as docu- 
ments in the host DLF library and retrieved to the production systems 
with DIF where they can be made into PROCs with the CPROC command. 
This requires intervention on each production 8100, though HCF could 
be employed to perform the retrieval from a host attached terminal. 


e Procs may be created as documents on the test 8100, archived to disk- 
ette and distributed manually to the production systems where they can 
be made into PROCs with the CPROC command. This requires intervention 
on each production 8100. 


Note: Before it will be possible to distribute PROCs from the host, SYS- 
CONFG, SYSIMOD and RJE will need to be correctly configured, and the 
DEFINE HOST,ID= command will require to be issued to identify the host 
SSCP to DPCX. More information on sending PROCs to DPCX systems is to be 
found under "RJE System Programmer Features" in the DPCX RJE Installation 
and Operation manual. 


PROCs may be developed and tested at the test 8100 and sent to the host 
with RJE, so that they are known to work before being distributed through- 
out the network. (If DSX is used, they may be retrieved from the test 8100 
to the host.) 


There is no need to limit the host library of PROCs to only those that 
relate to defining the configuration; logon, operational and other PROCs 
could be maintained, with either one, network-wide version or a tailored 
copy for each DPCX system. The DPCX DOSF Command Procedures manual docu- 
ments the control statements used in creating PROCs, and the DPCX DOSF 
Command Reference describes the commands which may be used in them. 


//SENDPROC JOB GENER 

//REPRO EXEC PGM=IEBGENER 

//SYSPRINT DD SYSOUT=A 

//SYSIN DD DUMMY 

//SYSUT1 DD DSN=SYS2.DPCX.PROCS(SYSTEMAB) ,DISP=SHR 
//SYSUT2 DD SYSOUT=B , DEST=R91 


// 
Figure 42. Sending a PROC to a DPCX system from OS/VS: This job 


will send the 'SYSTEM' PROC for system ‘AB', to the DPCX 
system which is JES remote 91, from OS/VS. 
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* §S$JOB JNM=SSERV,CLASS=0 
// JOB SSERV 
// DLBL IJSYSSL, 'DPCX.PROCS ' 
// EXTENT SYSSLB,SYSWK4 
// ASSGN SYSSLB, 3330, VOL=SYSWK4 , SHR 
// ASSGN SYSPCH,X'OOD' 
// EXEC SSERV 
PUNCH X.SYSTEMAB 
/* 
/& 
* $$ EOJ 


* SSJOB JNM=SENDPROC , CLASS=0 

* ¢€$ PUN REMOTE=5 

// JOB SENDPROC 

// DLBL IJSYSCL, 'PROD.CORE.IMAGE.LIBRARY.C' 
// EXTENT SYSCLB,DOSRES 

ASSGN SYSCLB,SYSRES 

// ASSGN SYSPCH,X'OOD' 


// UPSI 1 
// EXEC DITTO 
SSDITTO CC 


SSDITTO EOJ 


ales 
cay 


ASSGN SYSCLB,UA 
/& 
* $$ EOJ 


Figure 43. Sending a PROC to a DPCX system from DOS/VSE: These 
jobs will send the 'SYSTEM' PROC for system 'AB', to the 
DPCX system which is POWER remote 5, from DOS/VSE. The 
example utilises the VSE/DITTO program product. 


The examples show how to send a PROC from an OS/VS host system to a DPCX 
system (Figure 42 on page 82) and from a DOS/VSE host system to a DPCX 
system (Figure 43). Note that it is easy to send one PROC to each DPCX 
system in the same job, but host job entry subsystems may concatenate out- 
put to the same remote station from different job steps so that DPCX would 
receive just one PROC. In consequence, transmit no more than one PROC to 
a given DPCX system in any one job. 


A technique which could be used to execute a PROC on each 8100 in the net- 
work is described in "Capturing DPCX Displayed or Printed Data at the 
Host" on page 110. 


6.2 ESTABLISHING SYSTEM VALUES 


The jobs illustrated in Figure 44 on page 84 (OS/VS) and Figure 45 on page 
84 (DOS/VSE) show the possible content of a PROC to establish system val- 
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ues and how it may be filed in a host library. Rather than have individual 
'SYSTEM' PROCs for each 8100, your installation may determine that these 
values will be identical at each 8100 and one network-wide PROC could then 
be maintained and filed in the host library under the name of ‘SYSTEM’. 


//LOADPDS JOB GENER 

//REPRO EXEC PGM=IEBGENER 

//SYSPRINT DD + SYSOUT=A 

//SYSIN DD DUMMY 

//SYSUT2 DD  DSN=SYS2.DPCX.PROCS(SYSTEMAB) , DISP=OLD 
//SYSUT1 DD * 


:REPLACE SYSTEM 10/18/82 
*PROC 
*CO wists THIS IS THE 'SYSTEM' PROC FOR SYSTEM AB *ievevc 


DEFINE CMDC=* 

DEFINE JOURNAL=YES 

DEFINE PROMPT=? 

DEFINE STARTUP=IPL 

DEFINE SEARCH=(PROC ,CMD,PGM) ,MODE=BASE 

DEFINE SEARCH=(PROC ,CMD,PGM) , MODE=TEXT 

*CQO DEFINE COMMAND ACCESS CODES COULD GO HERE 
*CO DEFINE SYSTEM SERVICE ACCESS CODES COULD GO HERE 
*EXIT 

/ w 

// 


Figure 44. Filing a "SYSTEM' PROC at an OS/VS Host: This job will 


place the 'SYSTEM' PROC for DPCX system 'AB' into an OS 
partitioned data set. 
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* $$ JOB JNM=LOADLIB ,CLASS=0 
// JOB LOADLIB 
// DLBL IJSYSSL,'DPCX.PROCS' 
// EXTENT SYSSLB,SYSWK4 
// ASSGN SYSSLB,3330,VOL=SYSWK4, SHR 
// EXEC MAINT | 
CATALS X.SYSTEMAB 
BKEND 
‘REPLACE SYSTEM 10/18/82 
*PROC 
*CO wiekee THIS IS THE 'SYSTEM' PROC FOR SYSTEM AB wvecvv 
DEFINE CMDC=* 
DEFINE JOURNAL=YES 
DEFINE PROMPT=? 
DEFINE STARTUP=IPL 
DEFINE SEARCH=(PROC ,CMD,PGM) ,MODE=BASE 
DEFINE SEARCH=(PROC,CMD,PGM) ,MODE=TEXT 
*CQ DEFINE COMMAND ACCESS CODES COULD GO HERE 
*CO DEFINE SYSTEM SERVICE ACCESS CODES COULD GO HERE 
*EXIT 
BKEND 
/ ws 
/& 
* $$ EOJ 


Figure 45. Filing a 'SYSTEM' PROC at a DOS/VSE Host: This job will 
- place the 'SYSTEM' PROC for DPCX system 'AB' into a DOS 
source statement library. 


6.3 ESTABLISHING OPERATOR PROFILES 


The PROC illustrated in Figure 46 is an example of how operator values 
might be established at a DPCX system. The JCL used to file it in a host 
library is the same as in Figure 44 on page 84 (OS), changing the PDS mem- 
ber name on the SYSUT2 DD statement from 'SYSTEMAB' to 'USERSAB', or in 
Figure 45 on page 84 (DOS), changing the CATALS card similarly. 


DOSF operator characteristics are assigned with the SYSXPRFL System Ser- 
vice, or for release 3 of DOSF with the PROFILE command. The command is an 
interface to full-screen menus, and not all of the different options can 
be entered in a PROC. In either case the values assigned should be 
recorded on a form such as the "Operator Profile Worksheet in Appendix A 
of the DOSF Planning manual, and are set by the control operator or other 
authorised operator, possibly from the host using HCF. 


To what extent operator definitions are established from the host as 
opposed to being generated by the DPCX control operator will depend on the 
way your installation is organised. It is probable that some definitions, 
such as those for the control operator, the RJE operator and the DOSF pat- 
tern operator will be established from the host. If DISOSS is employed, 
these operator definitions will probably be determined at the host, as 
they must be defined to the DISOSS host product. 
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*PROC © 
*CO 

DEFINE 
DEFINE 
DEFINE 
DEFINE 
DEFINE 
DEFINE 
DEFINE 
DEFINE 
DEFINE 
DEFINE 
DEFINE 
DEFINE 
DEFINE 
DEFINE 
DEFINE 
TEXT 


“REPLACE USERS 


10/18/82 


wees THIS IS THE 'USERS' PROC FOR SYSTEM AB ®ve 
OPID=1 , ACCESS=11111111, LOGPROC=LOGONCTL , MODE=COMMAND 
OPID=1 , PAUTH=YES , PSWD=PWCTLOP , SYSACC=11111111 

OPID=1 , JO=YES ,DESC='CONTROL OP. ' 

OPID=2 , ACCESS=11111111, LOGPROC=LOGONCTL , MODE=COMMAND 
OPID=2 , PAUTH=YES , PSWD=BACKUP , SYSACC=11111111 

OPID=2 , JO=NO ,DESC='BACKUP OP.' 

OPID=3 , ACCESS=10000111, LOGPROC=LOGON , MODE=COMMAND 
OPID=3 , PAUTH=NO , PSWD=PW3XYZ , SYSACC=00010001 

OPID=3 , JO=NO ,DESC='FANNY SLUMBER’ 

OPID=4 , ACCESS=00000111, LOGPROC=LOGON , MODE=COMMAND 
OPID=4 , PAUTH=NO , PSWD=PW4ABC , SYSACC=00000001 
OPID=4 , JO=NO , DESC='MAY CHATTERBOX' 

OPID=5 , ACCESS=00000111, LOGPROC=LOGON , MODE=COMMAND 
OPID=5 , PAUTH=NO , PSWD=PW5PQR, SYSACC=00000001 

OPID=5 , JO=NO ,DESC='SUSIE DOLITTLE' 


SPELPRFL 1,,,YES,YES 
SPELPRFL 2,,,YES,YES 
SPELPRFL 3,,,YES,YES 
SPELPRFL 4,,,YES,NO 
SPELPRFL 5,,,YES,NO 


BASE 
*EXIT 


Figure 


46. A 'USERS' PROC to define operators: This PROC will 
define the operators for DPCX system ‘AB’. 


6.4 ESTABLISHING SYSHOST VALUES 


The 'DEFHOST' PROC illustrated in Figure 47 is an example of how SYSHOST 
values might be established at a DPCX system. The JCL used to file it ina 
host library is the same as in Figure 44 on page 84 (0S), changing the PDS 
member name on the SYSUT2 DD statement from SYSTEMAB to HOSTAB, or in 
Figure 45 on page 84 (DOS), changing the CATALS card similarly. 


It may well be the case that the configuration of host options is the same 
for all 8100s, and in this case only a single, network-wide PROC need be 
maintained, and filed in the host library under the name of 'HOST'. 
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:REPLACE DEFHOST 10/18/82 
PROC 

*CO were’ THIS IS THE 'DEFHOST' PROC FOR SYSTEM AB weve 
DEFINE HOST, BATCHID=SIRF 

DEFINE HOST, BATCHID=DSX 

DEFINE HOST, ID=11 

DEFINE HOST, LUPGMID=(10,958) 

DEFINE HOST, LUPGMID=(11,958) 

DEFINE HOST, LUPGMID=(12,2570) 

DEFINE HOST, LUPGMID=(13,2570) 

DEFINE HOST, LUPGMID=(14,2570) 

DEFINE HOST, LUPGMID=(45 ,932) 

DEFINE HOST, LUPGMID=(49 ,977) 

DEFINE HOST, LUPGMID=(50,932) 

DEFINE HOST, LUPGMID=(52 ,932) 

DEFINE HOST, LUPGMID=(55 ,932) 

“EXIT 


Figure 47. A 'DEFHOST' PROC to define SYSHOST values: this PROC 
will define the SYSHOST values for system ‘AB' 


6.5 ESTABLISHING SYSCONFG VALUES 


SYSCONFG values may be displayed, changed or printed from an HCF-connected 
terminal. Note that you must sign on with either user number 1 (control 
operator) or 255 (service representative). Also, if you attempt to proc- 
ess the configuration (SYSCONFG option 3), you will need to be the only 
signed-on user with only one host-initiated session enabled and no other 
tasks started. Moreover, as this SYSCONFG option concludes with a re-IPL 
of DPCX you will only be able to regain your DPCX session without inter- 
vention at the 8100 if the DPCX system has an appropriate startup PROC 
specified which enables the host link. Processing incorrect SYSCONFG val- 
ues may well necessitate intervention at the 8100 site to recover. 


For recording SYSCONFG values, there are good work-sheets appended to the 
DPCX DOSF Installation manual; alternatively, the values may be printed 
with SYSCONFG and the print records retrieved and printed at the host with 
SYSINFOREF and the listing retained. See "Capturing DPCX Displayed or 
Printed Data at the Host" on page 110 for details of the procedure. 


6.6 ESTABLISHING SYSIMOD VALUES 


SYSIMOD values may be changed from an HCF-connected terminal. Note that 
you must sign on with either user number 1 (control operator) or 255 (ser- 
vice representative), and that changes made with SYSIMOD are only effec- 
tive after the next DPCX IPL. Specifying incorrect SYSIMOD values for 
option 1 (the host link) may well require intervention at the 8100 site to 
recover as it may not subsequently be possible to access the 8100 with 
HCF. 


For recording the values, work-sheets are recommended as follows accord- 
ing to SYSIMOD option group: 
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. Option 1 - Host Link: use a form such as that in Figure 72 on page 
LIS 


° Option 2 - Print Group Table: use a form such as that in Figure 73 on 
page 174. 


e Option 3 - Transaction Data Set Group Table: if you have coded your 
own applications and need to define this table, use a form such as 
that in Figure 74 on page 175 to record the information. 


e Option 4 - System IOCBs: you should not normally require this option 
- the DPCX system will determine what devices are directly attached. 


e Option 6 - LU/LA Table: use forms such as those in Figure 75 on page 
176 and Figure 76 on page 177. 


° Option 7 - RJE Parameters: use a form such as that in Figure 77 on 
page 178. | 

e Option 8 - System Options: use a form such as that in Figure 78 on 
page 179. 


. Option A - Data Link Adaptors: use forms such as those appended to 
the DPCX DOSF Installation manual. 


: Option B - Directly Attached Loops: use forms such as those appended 
to the DPCX DOSF Installation manual. 


: Option C - Printer Matrix: use a form such as that in Figure 79 on 
page 180. 


With DPCX release 3.0 and its full-screen SYSIMOD function, the alterna- 
tive exists of printing the values with SYSIMOD, retrieving the print 
records and printing them at the host with SYSINFOREF and retaining the 
listing. See "Capturing DPCX Displayed or Printed Data at the Host" on 
page 110 for details of the procedure. 


6.7 ESTABLISHING SYSRJE VALUES 


There is some data which needs to be defined before RJE may be used. It is 
set with the SYSRJE System Service, in field by field mode of operation 
rather than command mode. These values may be set from the host by signing 
on as the RJE operator via HCF. 


There are two things to be established: 


. RJE signon parameters. These are set by SYSRJE option 7.1, and up to 5 
sets may be supplied. More than one set will be wanted if you want to 
communicate with different host systems, or if you want to have dif- 
ferent logmode tables available; for instance, to select from various 
sets of pacing parameters, or to have an option to use SNA compaction 
when desired. A sample form which may be used to record this data is 
shown in Figure 80 on page 181. 


° RJE FCBs. Any FCB which an RJE data-stream may request needs to be 


defined to DPCX. This is done with SYSRJE option 7.2; a sample form 
for recording the data is included in Figure 81 on page 182. It is 
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assumed that the definition or an FCB will be the same at each 8100 
which may utilise it - that is, these definitions are network-wide. 


6.8 ESTABLISHING DOSF VALUES 


DOSF values may be set (with SYSXGEN) or changed (with SYSXMNT) from an 
HCF-connected terminal. Note that you must sign on with an authorised user 
number. 


For recording SYSXGEN/SYSXMNT values, you may use a worksheet such as that 
in Figure 82 on page 183, or, once set, the values may be printed by any 
user with SYSXFEA3 option 5, the print records retrieved and printed at 
the host with SYSINFOREF and the listing retained. See "Capturing DPCX 


Displayed or Printed Data at the Host" on page 110 for details of the pro- 
cedure. 


6.9 ESTABLISHING DOSF QUEUE DEFINITIONS 


The definitions for standard DOSF queues to be used at a DPCX system 
should be determined and recorded on a form such as the Print Queue Work- 
sheet in Appendix A of the DOSF Planning manual. 

The worksheets may be sent to the control operator who can then define the 


queues, or they may be defined by host personnel with SYSXCTRL from an 
HCF-connected terminal using an authorised user number. 


6.10 ESTABLISHING DTF SESSION DEFINITIONS 


If your installation uses DISOSS or DIF, you will need to define some doc- 
ument transfer facility (DTF) sessions using the SYSXSDEF System Service. 
Record the values to be used on forms such as those in Figure 83 on page 
184 and Figure 84 on page 185. 

You may obtain a listing at the host of what is actually defined by: 

. Invoking SYSXSDEF 

° For each defined session, taking the option to Document it 

Either: 

e Store the resultant documents at the host with DISOSS 

° Print the documents at the host using DISOSS Host Print 

Or: 

° send the resultant documents to a host DLF library with DIF 

° Print the documents at the host using DCF 


Or: 
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. Using the CPROC command turn each document into a PROC 


: Add appropriate host JCL (to print the input stream at the host) to 
the PROCs with SYSEDIT 


° Submit these jobs to the host using RJE 


Those of the above processes which are done on the 8100 may of course be 
performed from the host using HCF. 


6.11 ESTABLISHING THE LAYOUT OF LOOPS 


In order to be able to resolve errors that occur in the physical compo- 
nents of loops it is essential that you know the sequence in which wrap 
loop station connectors and loop wiring concentrators occur, and which 
radial loop station connector is connected to which spur of the concentra- 
tor. It is imperative that each loop station be assigned a number with 
which it should also be labelled, and that the identity of the adjacent 
stations be known. 


In order that this information be available at the host, some form of loop 
map should be maintained and a copy be kept at the host. The loop layout 
chart referred to in the IBM Multiuse Communication Loop Planning and 
Installation Guide is an example. This manual contains very detailed 
information on procedures to follow when planning and installing the loop, 
and it should be consulted. 


6.12 ESTABLISHING TERMINAL ADDRESSES AND SETUP OPTIONS 


It is important to maintain a record of what devices are configured on a 
DPCX/DOSF system, and how they should be set up. DPCX has a concept of 
logical addresses (LAs) by which it accesses all its devices. There is a 
pre-determined addressing architecture: LAs exist for so many of each 
device, whether or not they are present, and the logical addresses deter- 
mine the physical addresses of devices. 


Appendix £ of the DPCX System Services manual contains a chart setting out 
all the logical addresses in the system. Use this, in conjunction with 
forms such as that in Figure 85 on page 186, to record addresses, 
description, identity and location of each device. Use one (or more) forms 
for each 8100 system, and create entries just for the subset of possible 
devices which is actually present on the system. 


A record of setup options for those devices designated as customer setup 
should also be kept at the host. The data to be recorded will vary with the 


device in question, but there may be an appropriate form shipped with it 
on which you may record the options. 


6.13 ESTABLISHING NETWORK RESOURCE INFORMATION 


You will need to keep a record of the network resource names by which VTAM 
knows the DPCX/DOSF systems. The relevant portion of the data already 
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recorded by network administrators or system programmers when defining 
the resources to VTAM, which should at the very least be NCP source state- 
ments with comments imbedded, should be adequate. The information should 
correlate the VTAM PU and LU names with the identification of the DPCX 
system and the NCP local addresses. 


Against this information it is convenient to record the DOSF system iden- 
tification code if DISOSS is used and the work station remote number if 
RJE is used. In addition, the naming convention used for defining logical 
units for DPCX systems should be documented with a record of the purpose 
that each is put to. It is suggested that you have a convention whereby the 
first part of the LU name identifies the DPCX system to which it belongs, 
while a suffix corresponds to a given NCP local address and DPCX usage. 
The DPCX usage should be consistent across 8100s; if an application is not 
used at some DPCX system and so requires no LUs, these LUs can be omitted 
from the NCP generation for that 8100, but should not be used for some 
other application. 

If the NLDM program product, 5668-971, is available it provides the capa- 
bility to display readily network resource names and associated informa- 


tion, and can reduce the amount of information which needs to be written 
down. See the NLDM General Information manual for more information. 


6.14 OVERVIEW OF THE INFORMATION/MANAGEMENT PROGRAM PRO- 
DUCT 


Information/Management is a feature of the Information/System program 
product, 5735-0ZS. This product offers management facilities in three 
areas: | 

: Configuration Management 

° Change Management 


° Problem Management 


Within these categories, Information Management offers functions as fol- 
lows: 


1. Configuration Management: maintaining inventory records for: 
°¢ Data Centres (network computing locations) 
e Systems at a centre 
° Hardware and software components comprising a system 
e Features of a component 
. Connections between components 
. Financial data 
e Service organisations 
2. Change Management: 


e Change requesting 
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. Assessing impact of changes 
e Change scheduling 
° Change approval 
° Change coordination 
° Change implementation 
e Post-change review 
3. Problem Management: 
° Problem reporting 
: Problem assigning 
: Problem coordination 
° Problem tracking 
‘ Problem analysis 
: Problem resolution 


To support these functions, Information/Management has a database with 
these capabilities: 


° Record creation, update, copying and deletion. 


° Record search and retrieval, using a flexible free-form search argu- 
ment. 


e Report generation: printing online search results lists and standard 
or customised reports. 


For more information on this product, read the Information/System General 
and Preinstallation Information manual. 
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7.0 PLANNING FOR DISASTER RECOVERY 


What would you do if a fire destroyed one of your DPCX/DOSF systems? 


Disaster recovery is the process of regaining an operational system after 
a catastrophic hardware or software error, or external physical damage, 
has rendered it unusable. It is assumed that such an eventuality will 
require the system to be re-created, either by re-generation or restoring 
from some form of backup, or some combination of both techniques. 


In planning for disaster recovery, it is important to strike a balance 
between on the one hand consuming a large amount of time preparing for a 
contingency which may never arise, and on the oth23r being unable to 
recover vital information if the unthinkable does happen. The minimum 
that should be done is to classify all that goes to make up a DPCX/DOSF 
system into that which can be re-created if a system is lost and that 
which can not, and should hence be backed up in some way. Procedures may 
then be put in place to ensure that data which could not be re-created is 
periodically saved. 


This chapter has two sections. They describe: 
° What could be re-created, and how to re-generate it. 
° What could not be re-created, and how to save it. 


The lists are not exhaustive; the purpose of including them is to focus 
awareness on the need for disaster recovery planning. They should prompt 
you to give a little thought to the procedures required to ensure that 
recovery of a DPCX/DOSF system after a catastrophic error is at least pos- 
sible. 


7.1 DATA WHICH CAN BE RE-CREATED 


This section lists some of the data on the system which it will be possi- 
ble to re-create, and the way in which this could be done. 


° System software. This would be re-installed by an initial install of 
the current releases as in "Base Code Initial and Update Installation" 
on page 7. PTFs would be sent again as mentioned in "Installing PTFs 
after an Initial or Update Install" on page 55. 


e Application software. This, being maintained on the SYSINFOREF 
BHDSSIL dataset while in use at DPCX systems, could be sent again. 


° PROCs - originated at the host. Those PROCs developed centrally at the 
host should be retained there while in use in the network, and these 
would be sent again (see "Distributing PROCs from a Host to DPCX Sys- 
tems" on page 81). 


° Configuration Information. Some of this may be available in PROCs 
developed at the host. The rest should be available for reconstruction 
of a DPCX/DOSF system if it was recorded as suggested in "Configura- 
tion Information that Should Be Recorded" on page 81. 
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Operator definitions - originated at the host. If the suggestions of 

"Establishing Operator Profiles" on page 85 are followed, these would 
be available in part in PROCs, with a manual record of DOSF parame- 
ters. 


DOSF queue and DIF session definitions - originated at the host. If 
these are documented as suggested in "Configuration Information that 
Should Be Recorded" on page 81 the information to re-create them would 


be available. 


User Datasets. If the application is one in which the 8100 holds a 
copy of some host data, it should be possible to rebuild the datasets 
from the host. 


7.2. DATA WHICH CANNOT BE RE-CREATED 


This section lists some of the data on the system which it will not be pos- 
sible to re-create, unless precautions are taken to save it periodically, 
with the tools indicated. 
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PROCs - originated at DPCX. Locally written PROCs should be saved on 
diskette if the control operator wants to be sure that they will 
always be available in the future. 


Operator definitions - originated at DPCX. If the control operator 
establishes operator profiles, they should be listed periodically 
with the DOSF SYSXPRFL system service and the information retained in 
case you ever need to re-create them. 


DOSF queues and DTF sessions - originated at DPCX. If the control 
operator defines queues or sessions the definitions should be saved on 
to diskette with DOSF system services SYSXCTRL and SYSXSDEF respec- 
tively. 


DOSF documents: any document which you are not prepared to risk having 
to re-key should be archived, either to diskette or to the host. 


User datasets: any user datasets containing data which cannot other- 
wise be re-created may be saved on diskettes. Relative and indexed 
datasets can be dumped us ing the DPCX SYSCOPY system service. RSDS 
datasets can be dumped using the 8100/DPCX RSDS File Re- organisation 
and Backup Utility field developed program (number 5798-DJJ) or simi- 
lar. If the DPCX system ever has to be rebuilt, the datasets could be 
restored from the diskettes. 


Note that the DOSF supplemental spelling dictionary and data diction- 
ary are user datasets of which you may wish to save copies. 
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PART 3: PROBLEM MANAGEMENT 


This section of the manual should be read by host Help Desk personnel 
responsible for assisting DPCX users, and by network administrators and 


system programmers responsible for problem determination throughout the 
network. 
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8.0 INTRODUCTION TO PROBLEM MANAGEMENT 


Problem Management is the process of resolving problems in the network; it 
can be described as a system containing the following elements: 


e Problem Recognition 

° Problem Reporting and Logging 
. Problem Determination 

e Problem Bypass and Recovery 

e Problem Resolution 

e Management Review 


Problem Recognition occurs when the existence of a problem is identified 
through a symptom or trend, or a deviation from what is usual. The dis- 
cussion in this part of the manual presumes the recognition of problems 
will have already occurred. 


Problem Reporting and Logging is the process of recording information 
about the problem for coordination, subsequent problem determination and 
eventual resolution. A basic assumption is that some sort of user help 
desk exists in your organisation, to which DPCX control operators, having 
recognised a problem, will report it. Help desk personnel, working with 
network administrators and system programmers, are responsible for prob- 
lem determination. 


Problem Determination involves the collection and analysis of data to iso- 
late and identify the failing component. It is the major topic considered 
in this chapter, since much is specific to the DPCX/DOSF environment. 


Problem Bypass and Recovery entails restoring the affected function 
through bypass and recovery procedures. 


Problem Resolution means the correcting of the problem by repairing the 
failing component. For problems that are determined to be caused by soft- 
ware malfunctions, this will usually involve the application of a PTF, and 
the processes involved are discussed in "PART 1: SOFTWARE MANAGEMENT" on 
page 3. 


Management Review is the process of ensuring that the problem management 
system functions effectively. It is not discussed here. 


For more information on a structured approach to problem management, with 
particular reference to the help desk and problem recording and logging, 
ask your IBM representative for an appropriate installation management 
guide. Half the effort involved in problem determination may be elimi- 
nated by properly recording a description of the problem and subsequently 
tracking progress on the investigation of the incident. The Informa- 
tion/Management feature of the Information/System program product, 
5735-0ZS, described in "Overview of the Information/Management Program 
Product’ on page 90, contains functions to assist in problem management. 


A diversity of tools for problem determination is considered in this chap- 


ter. Figure 48 on page 98 and Figure 49 on page 99 attempt to indicate to 
what type of problems each one is applicable. All these tools are dis- 
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Figure 48. 


cussed in more detail in other publications; Figure 50 on page 100 con- 
tains a list indicating to which manual to refer. This part of the manual 
focuses in two further chapters on two areas of problem determination of 


Dskt= diskette, Term= terminal, Perf= performance, Apps= Application 


Matrix of problem types against applicable host 
tools: the diagram indicates which tools available at 
the host may be used in determining various types of 
problems. 


specific relevance to a network of DPCX/DOSF systems: 
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"Aids for Determination of Network Problems.’ 
purpose communication network management tools are described briefly; 


DPCX techniques in more detail. 


"Performing DPCX Problem Determination from the Host" on page 109. 
Specific techniques for this purpose are discussed here. 
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Dskt= diskette, Term= terminal, Perf= performance, Apps= Application 


Figure 49. Matrix of problem types against applicable DPCX 
tools: the diagram indicates which tools available at 
the 8100 may be used in determining various types of 
problems. + 
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HCF HCF Guide and Reference 

SYSINFOREF Host Prep Sysinforef Guide and Reference 

Journal DPCX DOSF Command Reference 

Messages DPCX DOSF Messages and Codes 

*DISPLAY DPCX DOSF Command Reference 

*QUERY DPCX DOSF Command Reference 

SYSCONFG DPCX DOSF Installation 

SYSDC DPCX System Services 

SYSDEBUG DPCX Terminal Operations Program Execution Monitor Guide 


SYSDVAR DPCX DOSF Diagnosis Guide 


SYSIMOD DPCX DOSF Installation 
SYSLDSA DPCX System Services 
SYSLTSD DPCX System Services 
SYSRIS DPCX DOSF Diagnosis Guide 


SYSSPREC DPCX System Services 

SYSTCM DPCX System Services / DPCX DOSF Diagnosis Guide 
SYSTEST DPCX Terminal Operations Program Execution Monitor Guide 
SYSTRACE DPCX DOSF Diagnosis Guide 

SYSXFEA3 DOSF System Services 

Figure 50. Reference of manuals for problem determination 


tools: the list gives the manual which documents the 
named problem determination tool. 
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9.0 AIDS FOR DETERMINATION OF NETWORK PROBLEMS. 


This chapter contains brief descriptions of two general purpose communi- 
cation network management products: 


° Network Communications Control Facility 

: Network Problem Determination Application 

Although it is desirable to be able to resolve all network problems from 
the host site, there will be times when information is needed from DPCX. 


In consequence, this chapter also contains information on specific DPCX 
tools which are of use in diagnosing network prcblems. 


9.1 OVERVIEW OF THE NETWORK COMMUNICATIONS CONTROL FACIL- 
ITY. 


The Network Communications Control Facility (NCCF), 5735-XX6, is a pro- 
gram product designed to let you control, record and automate various 
operator tasks entailed in running your network. NCCF can be used as an 
operator interface to VTAM. It provides optional logging to disk or print- 
ers of operator interactions. NCCF operates as a VIAM application program 
in OS/VS1, OS/VS2 MVS or DOS/VSE, using 3270 devices as operator terminals 
and hardcopy printers. 

NCCF is a program base for communication network management. In addition 
to providing facilities for control of network operation and automation 
thereof, programs may be run in conjunction with NCCF and using its ser- 
vices, to address the following areas: 

. Network operations management 

. Problem determination 

: Configuration management 

e Change management 

. Problem management 


These programs may be IBM program products or user written. 


A brief summary of some NCCF facilities is set out below. More information 
may be found in the NCCF General Information manual. 


9.1.1 MAJOR NCCF FACILITIES 


This is a list of some of the more important facilities that NCCF pro- 
vides. 


e Multiple network operators are supported. Each may have different 
assigned responsibilities, and they may be at various locations 
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throughout .the network. They may use VIAM commands to display and mod- 
ify the network. 


e NCCF running under ACF/VTAM with the multisystem Networking Facility 
allows an operator to communicate with NCCF in another domain, and 
effect execution of commands in other domains and receive responses. 


e An operator's Span of Control may be restricted to a subset of the 
network's resources. 


e A Scope of Commands and operands may be defined so as to make those 
designated available only to certain operators. 


e Security is provided by checking operator logons. 


ad Command Lists of commands and control statements may be stored and 
subsequently executed. Variables may be substituted and conditional 
execution is provided. 


e Commands or command lists may be initiated by timer events. An initial 
command or command list can be executed when NCCF is started. 


° An optional Terminal Access Facility feature is available which can 
enable an NCCF terminal to function concurrently as a CICS, IMS and 
HCF console. 


ae OVERVIEW OF THE NETWORK PROBLEM DETERMINATION APPLI- 
CATION | 


The Network Problem Determination Application (NPDA) Version 2, 5668-983, 
is a program product which provides an orderly and systematic approach to 
isolating and correcting problems within a communications network and the 
host system. 


Running as a command processor under NCCF, NPDA collects event and statis- 
tical records from those components that issue them, stores them in a data 
base, and displays them at an NCCF operator station. 


By reporting the activities of the hardware and software components indi- 
cated by these records, NPDA identifies potential problems and permits 
them to be resolved before they seriously affect system operation. In 
addition, NPDA helps to locate failing components and suggests actions to 
restore their function. 


The information generated by resources is collected, organised and inter- 
preted for easy understanding, and may be displayed on a terminal for 
ready analysis. Included in this information are user-defined and 
NPDA-generated alert messages, which are high-priority messages used to 
identify the more serious problems and bring them to the attention of 
appropriate persons. 


A brief summary of NPDA facilities is set out below. More information may 
be found in the NPDA General Information manual. 
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9.2.1 NPDA FACILITIES 
To assist you in performing problem determination, NPDA: 


: Collects, stores and interprets information about detected events 
from those resources that provide such information. 


° Collects, stores and interprets statistical information from those 
resources that provide such information. 


e Issues situation alerts about potential problems to appropriate per- 
sonnel. Alerts are generated by the occurrence of certain events or 
when user-set thresholds are exceeded. 


: Recommends possible user activities to locate and relieve problems. 


e Can transfer selected information to the data base of the Informa- 
tion/Management feature of the Information/System program product, 
5735-OZS. 


° Allows a user access, via his NCCF display terminal, to the accumu- 
lated information, which includes: 


— Identification of the resource. 
—- A description of alerts and events. 


— The probable cause of alerts and events based on an analysis of 
the recorded data. 


— The recommended action that the user may follow to correct or cir- 
cumvent the problems described in an alert or event. 


— Accumulated statistics about temporary, or recoverable, error 
events that may be used in the analysis of performance degradation 
or intermittent failures. 


9.3 NETWORK PROBLEM DETERMINATION WITH DPCX 


The presence of DPCX/DOSF systems in a network has implications for the 
network problem determination which is carried on from the host. In par- 
ticular, the host TP access method cannot "see through" DPCX, and does not 
know what devices lie beyond it. This section discusses problem determi- 
nation for DPCX as seen from the host, and the DPCX facilities applicable 
to the devices beyond DPCX. 


9.3.1 DPCX CONSTRAINTS ON HOST NETWORK PROBLEM DETERMI- 
NATION 


Because an 8100 with DPCX is a computing system in its own right, capable 
of functioning when the host is offline, the first priority of DPCX when 
an error occurs is to tell its control operator. Under many circum- 
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stances, the host system will not know when something goes wrong with DPCX 
or any terminal downstream of it. 


: No alerts are generated by DPCX 


The Physical Unit type 2 in the 8100/DPCX/DOSF system generates no 
messages to the VTAM SSCP reflecting errors occurring in DPCX. 


- No alerts are passed to the host on behalf of, or errors reported con- 
cerning, devices downstream of DPCX. 


When devices downstream of DPCX generate messages to the SSCP to 
report errors, DPCX does not pass them through to the host SSCP. 


. There is no programmed operator facility. 


DPCX does not support the capability to create a program to intercept 
messages to the control operator and handle the conditions to which 
they refer according to user specifications. 


Although DPCX is not transparent to host network management software, it 
does contain a variety of aids of its own. "Aids for Network Problems 
Downstream of DPCX" on page 107 suggests how these may be used to perform 
problem determination in the network downstream of DPCX. "Performing DPCX 
Problem Determination from the Host" on page 109 discusses accessing these 
aids from the host site. 


9.3.2 DIAGNOSING HOST LINK PROBLEMS 


If communications cannot be established between DPCX and the Host, the 
DPCX tools for link problem determination cannot be used by host personnel 
as their access to the DPCX system is via the very link which is not work- 
ing. In this event, the problem should be investigated as far as possible 
from the host; if this does not reveal the cause of the trouble, then host 
personnel must specify a course of diagnostic action to the DPCX control 
operator, who should report the results to them. 


9.3.2.1 Diagnostic Actions from the Host 


The procedure which follows assumes the use of 386x modems on the host 
link in conjunction with NPDA on the host. If 386x modems and/or NPDA are 
not employed, various manual modem wrap tests and other procedures will 
have to be used to gather equivalent information. 


If the host link is not working, it will probably be the DPCX control 
operator who reports the problem. Follow these steps: 


1. Use the VTAM display commands to determine the status of the network 
resources constituting the DPCX system and the network path to it. If 
there was a failure in the host or in the network out to and including 
the NCP with which the DPCX system communicates, correct that first. 


2. If the DPCX system had been communicating with the host, and then a 


failure occurred, NPDA should have reflected an alert to an NCCF con- 
sole. By selecting that alert, from the information obtained from the 
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386x modems, NPDA should venture its opinion as to whether the failure 
was in the local modem, TP link, remote modem or in the 8100. In the 
last instance, all NPDA can know is whether or not the DPCX system is 
responding to the modem. 


3. If the DPCX system was in a normal inactive state, but the PU does not 
activate, use the NPDA TEST command to obtain the same information as 
is collected automatically in the event of a failure. 


4. If the above steps indicate no errors, you know that you have a good 
network path to the DPCX system and you will need to follow the course 
of diagnostic actions from DPCX which follows this section. 


In the event that the PU is active, but some part of host communications 
will not work or malfunctions, VTAM traces are available to assist in 
diagnosing the problem by tracing sessions to LUs or the PU. 


The NLDM program product, 5668-971, has very useful trace capabilities. It 
offers significant usability features, such as: 


° Supporting interactive display of traced session data from an NCCF 
terminal 


° Optionally having the trace switched on for all sessions, or all of a 
certain type, (for instance SSCP to LU), so that errors may be traced 
as they occur without having to re-create the problem. 


See the NLDM General Information manual for more information 


9.3.2.2 Diagnostic Actions from DPCX 


If network problem determination from the host fails to identify the cause 
of the problem, or suggest some specific thing to investigate at DPCX, 
have the control operator follow this course of action: 


1. Issue the QUERY TASKS command. If program number 954 is not present 
running on LA EO, host communications has not been started or has ter- 
minated: issue the ENABLE HOST command. 


2. If the host link had been started, but has terminated, or if program 
954 is not running after an ENABLE HOST command, check that a system 
message has not been issued to the control operator. If necessary, 
checkpoint and print the journal to review the messages to operator 1. 
If there was a message, follow the action suggested in DPCX DOSF Mes- 
sages and Codes. 


3. Issue the DISPLAY HOST command. Report the results to the help desk. 


The procedure from here on should be followed in co-operation with the 
help desk or network operations. 


4. If the modem is not shown as connected, there may be a fault with the 
TP line or modem equipment. If the host link employs a switched con- 
nection, it is possible that it is not connected. Re-dial it to make 
certain. Host network operators should be able to diagnose a fault by 
specifying modem wrap tests to be carried out, or using NPDA if the 
modems have link test capability. 
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10. 


If the host tests work, there may be a fault in the 8100 adaptor or 
modem interface. The diagnostic tests available with. SYSHOST epeacn 
group 4 should fail if this is the case. 


Note: It is strongly recommended that you configure DPCX using SYSI- 
MOD option group 1 for automatic tests, so that this diagnostic is run 
automatically each time the host is enabled or it fails. 


If the host wrap tests were successful but the DPCX diagnostic failed, 
inspect the physical cable connection between the 8100 and the host 
link modem. If this properly fastened in, use the 8100 system verifi- 
cation diskette obtained when the 8100 was installed to check the 8100 
hardware and modem interface. If this test fails, contact your ser- 
vice representative for assistance. 


If the modem is shown as connected, but the 3705 is not, the NCP is not 
polling the 8100. The network operator should ensure that the NCP is 
functioning correctly and the host network resources which represent 
the 8100 are not deactivated. 


If either of the two above conditions applies, and the suggested 
actions have not corrected the problem, make certain that the SYSIMOD 
option group 1 values which define the host link parameters are set 
correctly. Prior to release 3 of DPCX you can do this by stepping 
through the responses to SYSIMOD option group 1, not changing those 
values which are correct. For release 3, you can display the values. 


In particular, having any of the following incorrect will ensure that 
host communications cannot be enabled. 


e Station Id (for a switched connection) 

° Station address 

. NRZI encoding 

e Request-to-send setting 

If anything is wrong, correct it with SYSIMOD. 

If the 3705 is shown as connected, but.the host is not, the host sys- 
tem has deactivated the processor. The network operator should 
attempt to re-activate it. 


If everything so far is active, check 


a. The 8100 has enabled some LUs; if it has not use SYSHOST option 
group 1 to enable logical units. 


b. The host has enabled some LUs; if it has not the network operator 
should attempt to activate them. 


c. The host and DPCX have enabled the same LUs. Use the DISPLAY HOST 
command with the LU operand to look at the status of the individ- 
ual LUs which you expect to use. If different LUs are being acti- 
vated you have some network administration to sort out. 


If a DPCX software malfunction is ever suspected in connection with host 
processing, SYSTRACE (for releases prior to 3.0) and the TRACE command 
(for release 3.0 or later) contain the capability to perform host inter- 
nals traces. Prior to DPCX release 3.0 the data is wrapped in a storage 
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buffer; for release 3.0 and subsequent it is spooled to a user dataset. 
See the DPCX DOSF Diagnosis Guide for details. 


You should not normally expect to use this trace unless requested to do so 
by the IBM Support Centre. Tracing communications on the link is better 
performed from the host using standard VTAM traces??. 


9.3.3 AIDS FOR NETWORK PROBLEMS DOWNSTREAM OF DPCX 


Because the DPCX system is not transparent to host network management 
software, it is necessary to use DPCX techniques to perform problem deter- 
mination in the network downstream of the 8100. These tools are accessible 
from the host in one of two ways: 


By using them from a terminal connected via Host Command Facility 
(HCF), which is described in "Introduction to Host Command Facility’ 
on page 109, in the same way as they would be used from a native DPCX 
terminal. 


Some are implemented as functions of Host Prep SYSINFOREF, and these 
are described under appropriate headings in "Performing DPCX Problem 
Determination from the Host" on page 109. 


These are the DPCX facilities which will be of use for problem determi- 
nation in the network downstream of DPCX: 
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Journalling the control operator: messages which report errors from 
devices downstream of DPCX will be issued to the DPCX control opera- 
tor, user number 1. It is possible to "journal" the control operator 
so as to retain a log of these messages. 


Displaying the network: the QUERY TASKS command will display all 
devices currently allocated by DPCX. QUERY DEVAD= may be used to dis- 
play the status of an individual downstream network resource. 


Network Configuration: the SYSCONFG and SYSIMOD DPCX System Services 
define, and can display, the configuration of the downstream network. 
The ENABLE and DISABLE commands may be used to activate and deactivate 
network resources. 


Retrieving incident records: errors occurring in the network down- 
stream result in entries being logged in the DPCX Condition Incident 
Log (CIL). The CIL has five types of records; those resulting from 
incidents relating to downstream network resources are type 3. Type 1 
incidents result from errors with 3270 or 3730 terminals attached to 
the display printer adaptor. 


SYSINFOREF provides a function to retrieve these records to the host. 
The RETRIEVE CIL statement followed by record selection options can be 
used to select just the records for one device. 


Alternatively, the ELSA function of DPCX R3 could be used via HCF. 
This allows CIL records to be interpreted and displayed on a screen, 


The host NLDM program product, 5668-971, if installed, has function 
which can reduce the need to take traces. 
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The 
for 


and the resulting report can be saved in the DPCX spool and retrieved 
as print records by SYSINFOREF. 


Retrieving control unit error logs: SYSINFOREF contains function to 
cause DPCX to retrieve, and pass back to the host, the control unit 
error logs of 3276 and 5210 devices. The RETRIEVE FIDLOG statement 
performs this service. 


Testing the downstream network: The DPCX System Service SYSTCM will 
perform online tests of DPCX links and loops and the downstream termi- 
nals that attach via them. SYSTCM also supports terminals which are 
connected to the 8100 display printer adaptor. 


In DPCX R3, SYSTCM has a new English-language (rather than Hex.) user 
interface, making it much easier to use than in earlier releases; also 
new in DPCX R3 is the TESTLNK command, which allows the diagnostic 
functions of IBM 386x modems on a downstream link to be exercised from 
a DPCX terminal or, via HCF, from the host. 


Invoking traces: DPCX supports four types of trace of its downstream 
communication ports: 


— SYSTRACE PCA SNA internals (DPCX release 3: TRACE PCA link); this 
traces internals of the DPCX code driving PCA loops and links. 


= SYSTRACE PCA I/O internals (DPCX release 3: TRACE PCA terminal); 
this traces internals of the DPCX code driving PCA terminals. 


- $YSCOMTF PCA SNA protocol trace; this can be invoked and retrieved 
with SYSINFOREF. 


a SYSCOMTF PCA data trace; the trace can be invoked, and its data 
retrieved, with SYSINFOREF. | 


Of these, you are more likely to need the last two traces than the 
first two. 


DPCX DOSF Diagnosis Guide for release 3 contains a chapter "Guidelines 
Handling Link and Loop (PCA) Problems" to guide you in the use of 


these tools for determining problems arising with terminals thus 
attached. 
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10.0 PERFORMING DPCX PROBLEM DETERMINATION FROM THE HOST 


This chapter describes how DPCX facilities may be accessed and used by 
host personnel for diagnosing problems in the DPCX system or in the net- 
work downstream of it. It does not give a comprehensive description of the 
purpose or capability of these tools. More information on each may be 
found by referring to the publication indicated in Figure 50 on page 100. 
Education courses are available on DPCX problem determination; contact 
your IBM representative for details. 


An introduction to Host Command Facility is followed by a consideration of 
ways to capture DPCXK displayed or printed data at the host, and then the 
various aids are considered in the following broad categories: 

e General aids 

e System problems (DPCX, DOSF and 8100 system units) 

° Disk and dataset 


e Application software 


e Network 


10.1 INTRODUCTION TO HOST COMMAND FACILITY 


The Host Command Facility (HCF), 5668-985, is a program product which 
gives a host system terminal user the ability to: 


: Interactively operate and control DPCX/DOSF operations within an 8100 
on an SDLC communication network. 


° Use the service facilities of an 8100. 
e Use DPCX application programs in a connected 8100. 


e Perform problem determination and error diagnostics throughout the 
network. 7 


HCF allows several host users to access different, or the same, DPCX sys- 
tems at the same time. There is a limit of three users who may concurrent- 
ly access any one DPCX system via HCF. HCF also supports 8100s running the 
DPPX operating system. 


Using HCF, any VTAM controlled display terminal (or NCCF terminal using 
the Terminal Access Facility), can operate as if it were a 327x 1920 char- 
acter display directly attached to DPCX. In this way, a user may issue 
DPCX or DOSF commands, use DPCX and DOSF System Services and run user or 
IBM-supplied application software from the host terminal, with the fol- 
lowing exceptions: 


e Programs cannot use a host-attached display or printer as a secondary 
or tertiary device. 


° Programs requiring DOSF text edit and entry capability, will not work 
if invoked from an HCF-connected terminal. Even if the terminal is an 
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IDTF 8775 accessing HCF from an 8100 via DSC, DPCX does not Support 
text edit and entry on an HCF terminal. 


HCF is an invaluable asset when attempting to perform DPCX problem deter- 
mination from the host, as in many instances it will allow the host user, 
who has greater expertise than the users at the 8100 site, to re-create 
and study for himself a problem which they have encountered. 


For more information on HCF, and details of its operation, consult the HCF 
Guide and Reference. 


10.2 CAPTURING DPCX DISPLAYED OR PRINTED DATA AT THE HOST 


Many of the procedures that are described in the following sections 
involve the use of DPCX System Services to display or print data from a 
DPCX system. This section suggests ways in which this data may be captured 
at the host, according to whether the System Service is invoked on a DPCX 
terminal at the 8100 site, or at the host site on an HCF-connected termi- 
nal. 


1. Control operator using a DPCX System Service on a DPCX terminal at the 
8100 site: 


a. Small quantities of data may be displayed or printed and the 
information manually reported to host personnel. 


Note: For a problem with which host communications cannot be made 
to work, you will need to resort to this technique. 


b. Data may be printed - that is, generated as a print sequence num- 
ber on the spool dataset - and retrieved to the host with SYSINFO- 
REF*?. The control operator must tell host personnel which PSN 
contains the data. 


2. Host personnel using a DPCX System Service from the host on an 
HCF-connected terminal: 


a. Small quantities of data may be displayed and the information man- 
ually recorded, or captured using control-unit local copy to a 
printer associated with the HCF terminal. 


b. Data may be printed - that is, generated as a print sequence num- 
ber on the spool dataset - and retrieved to the host with SYSINFO- 
REF? 


Note: HCF cannot be used to investigate a problem involving DOSF text 
edit and entry. 


Examples of DPCX data which you might want to obtain in hard copy at the 
host for problem determination include: 


° Control Operator Journals from the time of an error. 


12 With releases of Host Prep prior to 5.0, SYSINFOREF does not format 
the print records, which consist of compressed SNA character strings, 
and the listing of them is not readily intelligible. 
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e Configuration (SYSCONFG and SYSIMOD) data, to ensure that the system 
is correctly set up. 


e SYSRIS dumps of disk or storage records 


10.2.1 PURGING PSNS AFTER RETRIEVAL TO THE HOST 


Particularly when print spool records are being generated by host person- 
nel, procedures need to be instituted to ensure that the DPCX control 
operator leaves them alone - that is, neither prints nor deletes them. 
Conversely, after SYSINFOREF has retrieved them to the host, a procedure 
for deleting print spool records is needed; SYSINFOREF does not delete 
them after retrieval. 


Print spool records can be purged by command from an HCF-connected termi- 
nal, or by the control operator at the 8100 site, but it may be considered 
more convenient to delete them in the same SYSINFOREF jobstream as 
retrieves them. What follows is a technique by which this may be accom- 
plished’?. 


The method involves DPCX user programming, and allows a SYSINFOREF (or 
DSX) host session to invoke any DPCX PROC as a subtask. Success or failure 
messages, and messages from the PROC, are reflected to the host and can be 
retrieved by a subsequent SYSINFOREF job. 


To use the process, a DPCK user number is designated to receive messages 
from the host; the messages are in fact DPCX commands for execution by the 
host-initiated subtask. It is suggested that the DPCX user number be 
reserved - that is, not used by any DPCX operator, to avoid any possible 
retrieval of the messages from the host which would give confusing results 
both for the operator and for host personnel. 


This process only gives the SYSINFOREF user access to DPCX commands, and 
only those that issue no prompts to the operator. It gives him no access 
to DPCX System Services. As what is available to him is only a portion of 
the function provided by HCF, and is often less convenient to use, this 
technique should in no way be seen as a generally viable alternative to 
HCF. Its use for any given purpose should be carefully evaluated. However, 
the following are instances in which it may be effectively employed: 


° For the purpose addressed in this section, of deleting print records 
previously retrieved with SYSINFOREF. 


° To execute a PROC on each 8100 in the network, for instance those 
described under ''PART 2: CONFIGURATION MANAGEMENT" on page 77. 


The SYSINFOREF control statements to retrieve and delete PSN 31745 from 
DPCX system 'AA' are shown in Figure 51 on page 112 (use the same JCL as in 
Figure 61 on page 127), and the PROC in use at the DPCX system in 
Figure 52 on page 112. (How the PROC could be distributed to the DPCX sys- 
tems is suggested under "Distributing PROCs from a Host to DPCX Systems” 
on page 81.) A PROC will be necessary in most instances to allow the DPCX 
command to be issued from user number 251 under which the host-initiated 


13 This way of handling print spool records requires Host Prep release 


5.0 for the specification of ‘ALL' retrieving the PSN and to initiate 
the subtask. 
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subtask runs. The example shown uses a further capability of the sample 
program to return messages to the host when invoked from a PROC with an 
*CALL statement. 


The example assumes that user number 150 has been reserved for the purpose 
of communicating the instructions from the host, and that the program that 
the host initiates as a subtask is number 304. The source code of a work- 
ing sample is appended in "Sample Programs" on page 137. Once assembled, 
such a program may be distributed in the manner described under "Maintain- 
ing Application Software" on page 63. The status messages generated by the 
subtask may subsequently be retrieved by the SYSINFOREF control state- 
ments in Figure 53 on page 113. If this technique were in regular use the 
RETRIEVE HOST MSG statement would probably be used at the start of every 
SYSINFOREF session to retrieve any messages from previous host-initiated 
subtasks. 


& GENERATE SYSID(TEXTAA10) 5 
& RETRIEVE RECORDS (PRINT) ; 
31745 ALL 

& SEND MSG 

& OPID(150) PGMID (304) ; 
XPURGE PSN,31745 

& _ INITSUB(304) 3 
& END | ) 
& STARTCOM SYSID(TEXTAA10) ; 
& 3 


LIST RESPONSE (ALL) SYSID(TEXTAA10) 


Figure 51. Retrieving and deleting print spool records with 
SYSINFOREF: these control statements will retrieve and 
delete PSN 31745 if the sample program 304 is available 
at DPCX system 'AA'. Host Prep release 5.0 is required. 


*PROC , 

*CMOFF 

*IF &USERNO EQ 251 *SKIP 2 

*CO XPURGE: PROC FOR HOST USE ONLY. 

*EXIT 

*IF '&1' EQ 'PSt' *SKIP 2 

*CALL 304 XPURGE - OPERAND 1 INVALID. 

*EXIT 

*IF '&2' EQ '' *GOTO -ERROR2 

PURGE PSN=&2 

*IF &RETCODE EQ 0 *EXIT 

*CALL 304 XPURGE - RETURN CODE &RETCODE FROM PURGE PSN=&2. 
*EXIT 

-ERROR2 *CALL 304 XPURGE - OPERAND 2 INVALID. 
*EXIT 


Figure 52. Sample PROC to delete print spool records: the 'XPURGE' 


PROC allows a host-initiated subtask to delete print 
spool records. 
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GENERATE SYSID(TEXTAA10) 

RETRIEVE HOST MSG 

END 

STARTCOM SYSID(TEXTAA10) 

LIST RESPONSE (ALL) SYSID(TEXTAA10) 


Figure 53. Retrieving host-initiated subtask 
messages: these control statements will retrieve 
messages generated by the host-initiated subtask. 


10.3. USING GENERAL AIDS 


The aids referred to below are of general applicability to all sorts of 
DPCX problems. 


10.3.1 JOURNALLING THE CONTROL OPERATOR 


It is suggested that the DPCX control operator be journaled. This will 
help to ensure that control operator actions and system messages are 
recorded in the event of problems arising. To set this up on a DPCX system 


e Issue the DEFINE JOURNAL=YES command from user number 1. 


° Ensure that the control operator's number (1) is defined with the 
operand JO=YES. 


If problems arise which need investigation from the host, issue the com- 
mand JOURNAL CHKPT from user number 1, or other authorised user. This will 
cause the current PSN to be closed. The spool records may then be browsed 
at the host using an HCF-connected terminal, or retrieved to the host and 
printed as described in "Capturing DPCX Displayed or Printed Data at the 
Host" on page 110. 


Having journaling enabled causes a certain overhead on the DPCX system. To 
limit this: 

° Use the control operator signon only for system control functions. 

If, however, the system is very busy, journaling may be suspended tempo- 
rarily by issuing the command JOURNAL OFF. It will also be necessary to 
suspend journaling in order to use certain control operator functions 


which will not tolerate concurrent activity, but these are not often 
required in day to day operation of the system. 


10.3.2 RETRIEVING THE CONDITION INCIDENT LOG 


SYSINFOREF contains function supporting the retrieval of condition inci- 
dent log (CIL) records from a DPCX system. Using the RETRIEVE CIL state- 
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ment it is possible to retrieve the latest incident, all incidents or a 
count of incidents. These functions may be applied to all incidents in the 
log, all incidents of a particular type (types 1 through 5 exist), all 
incidents of a given type and a specific device address or system condi- 
tion, or a range of incidents using their sequence numbers. 


Unfortunately a range of incidents by date and time is not supported. In 
consequence, the best policy is to retrieve the CIL records from all DPCX 
systems regularly, say once a week, and clear the logs (this function is 
also supported from the host). Figure 54 shows how to do this. Use JCL as 
in Figure 61 on page 127, though you might want to leave the output held 
on the spool, or write it to disk or tape, and print or inspect it only if 
it is required to support problem determination. 


If you are clearing the CIL regularly, when problems arise you may run a 
transmission to retrieve all the relevant incident records, without 
receiving overwhelming volumes of out-of-date data. 


& GENERATE NETWORK 3 
& RETRIEVE CIL 3 
Z 
11 
8 
& END : 
& STARTCOM NETWORK : 
& LIST RESPONSE (ALL) ; 


Figure 54. Retrieving condition incident log records: these 
control statements will retrieve all CIL records from 
each 8100 in the network and print them. The logs are. 
cleared. 


10.4 SYSTEM PROBLEMS 


The tools that follow are applicable to general system problems with DPCX - 
and DOSF. Errors occurring in disk space allocation or in datasets are 
considered in "Disk and Dataset Problems" on page 117. 


10.4.1 VALIDATING THE CONFIGURATION 


Using HCF, it is possible to display a system's SYSCONFG and SYSIMOD 
parameters at a host terminal. Selecting the print option of SYSCONFG and, 
for DPCX release 3 or later, of SYSIMOD you may generate configuration 
listings as records in. the spool dataset. These may be retrieved to the 
host as described in "Capturing DPCX Displayed or Printed Data at the 
Host'' on page 110. 


The DOSF System Service SYSXFEA3 may also be invoked. This has an option 
to display the DOSF options configured with SYSXGEN. The data may either 
be displayed or spooled to a PSN where it is available for retrieval to 
the host. 


114 DPCX/DOSF Network Management 


Before looking further for the cause of a problem, it is wise to start 
here and check that no changes to the configuration have been made which 
might have caused the trouble. 


Note: The host user must sign on either as the DPCX control operator (user 
number 1) or as the service representative (user number 255) in order to 
use SYSCONFG or SYSIMOD. 


10.4.2 EXAMINING PERFORMANCE 


SYSDC may be started or stopped from the host by signing on via HCF with 
any DPCX operator number. It monitors processor, DASD and storage utili- 
sation. On a system installed with ASSIST the disk layout is predeter- 
mined, reasonably optimal and there is little opportunity to change it 
while still retaining ASSIST capability. The data captured by SYSDC in 
relation to storage utilisation comprises statistics of buffer pool 
usage. You may use this data to determine how best to distribute storage 
(with SYSCONFG) between resident programs, associative storage, transient 
buffers, multiple task storage and PCA buffers. 


The data SYSDC collects may be displayed on the HCF terminal, or it may be 
printed and the PSN retrieved to the host with SYSINFOREF as described in 
‘Capturing DPCX Displayed or Printed Data at the Host" on page 110. 


10.4.3 DPCX SYSTEM FAILURES 


There should be procedures which instruct the control operator to take a 
dump of processor storage when a DPCX system terminates abnormally, or 
enters a loop or wait condition. Instructions for this are in the DPCX 
DOSF Basic Operations manual. The dump program is IPLed from a diskette, 
and the dump is written either to diskettes or to an area on disk. 


A system dump may be retrieved to the host, and formatted there, using 
SYSINFOREF. If the dump is on diskettes the control operator has to load 
them in response to codes which appear on the 8100 operator panel. Note 
that you might have to retain the dump on diskette to send to the IBM sup- 
port centre. 


Figure 55 on page 116 and Figure 56 on page 116 show how to retrieve a 
dump from disk or diskette respectively. The numbers following the 
RETRIEVE SYSDUMP statement indicate the components to be retrieved. See 
the DPCX DOSF Diagnosis Guide for details as they change from release to 
release of DPCX. The LIST RESPONSE statement will produce an unformatted 
listing of the dump, while the LIST FORMDUMP statement yields a formatted 
one. The JCL to use is that in Figure 61 on page 127. 


You may also retrieve the task virtual storage paging areas; see the Host 


Prep SYSINFOREF Guide and Reference for the RETRIEVE SYSDUMP TVSPA state- 
ment. 
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& GENERATE SYSID(TEXTAC10) 
& RETRIEVE SYSDUMP 
O01 02 03 04 05 20 21 24 75 77 80 
END _ 
STARTCOM SYSID(TEXTAC10) 
LIST RESPONSE (ALL) SYSID(TEXTAC10) 
LIST FORMDUMP SYSID(TEXTAC10) 


3 
3 
e 
3 
3 


Figure 55. Retrieving a system dump from disk: these control 
statements will retrieve a system dump which was taken 
on disk from a DPCX system. 


GENERATE SYSID(TEXTAC10) 
RETRIEVE SYSDUMP 
02 03 04 05 20 21 24 75 77 80 
END ; 
STARTCOM SYSID(TEXTAC10) ; 
LIST RESPONSE (ALL) SYSID(TEXTAC10) ; 
LIST FORMDUMP SYSIDCTEXTAC10) : 
Figure 56. Retrieving a system dump from diskette: these control 
statements will retrieve a system dump which was taken 
on diskette from a DPCX system. 


10.4.4 TRACING SYSTEM ACTIVITY 


The DPCX traces may be used from the host via an HCF-connected terminal. 
They trace various system events, in a way that differs according to the 
release of DPCX. The DLA protocol and data traces are considered sepa- 
rately under "Network Problems" on page 120. 


1. For DPCX systems prior to release 3, traces are invoked with the SYST- 
RACE System Service, and the data is collected in a buffer in storage. 
Using the SYSRIS DPCX System Service this buffer may be displayed at 
an HCF terminal, or printed to the spool dataset. The spool records 
may be retrieved to the host as described in "Capturing DPCX Displayed 
or Printed Data at the Host" on page 110. They are also formatted 
along with a system dump, if a trace was active when the dump was tak- 
en. 


The SNA internals trace, SYSTRACE type 7, is an exception in that it 
is spooled to a system dataset. This trace may be formatted to the 
spool dataset with SYSTROUT, and the resulting PSN browsed, or 
retrieved to the host as above. 


Note: The host user must sign on either as the DPCX control operator 
(user number 1) or as the service representative (user eae 255) in 
order to use SYSTRACE, SYSTROUT or SYSRIS: 


2. With DPCX release 3 and subsequent, SYSTRACE is replaced by the TRACE 


command. Signing on via HCF, a host user can use this to allocate a 
user dataset to which traced events are spooled when a trace is start- 
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ed (with the TRACE command). Another variation of the command causes 
these records to be formatted to the print spool. From here the HCF 
user can browse the PSN, or retrieve it to the host as described in 
"Capturing DPCX Displayed or Printed Data at the Host” on page 110. 


10.4.5 DISPLAYING PROCESSOR STORAGE 


Logical storage of an 8100 may be inspected from the host while DPCX is 
operating. Use the SYSRIS DPCX System Service from a terminal connected 
via HCF. Storage blocks may also be printed with the print option, and the 
resulting print spool records retrieved to the host as described in ''Cap- 
turing DPCX Displayed or Priated Data at the Host" on page 110. 


Note: The host user must sign on either as the DPCX control operator (user 
number 1) or as the service representative (user number 255) in order to 
use SYSKIS. 


10.4.6 ANALYSING TAPE VOLUME ERRORS 


A host user may use the DPCX SYSLTSD System Service from an HCF-connected 
terminal to analyse tape errors by volume. SYSLTSD will display errors by 
volume for up to eighty tape volumes. The same data may be printed, and 
the spool records produced may retrieved to the host as described in "Cap- 
turing DPCX Displayed or Printed Data at the Host" on page 110. 


Note: The host user must sign on either as the DPCX control operator (user 
number 1) or as the service representative (user number 255) in order to 
use SYSLTSD. 


10.5 DISK AND DATASET PROBLEMS 


The tools described below can be used to report on disk and dataset lay- 
outs, and to examine blocks on disk and records of datasets. 


10.5.1 LISTING CATEGORY AND DATASET ALLOCATIONS 


A user at the host can, from a terminal signed on to HCF, display the 
assignment of bitmaps and datasets to categories and the allocation and 
characteristics of datasets. The DPCX System Service SYSLDSA is used for 
this purpose. 


The same information may be printed to the spool, again using SYSLDSA, and 
the print records retrieved to the host with SYSINFOREF as described in 
"Capturing DPCX Displayed or Printed Data at the Host" on page 110. 


Note: The host user must sign on either as the DPCX control operator (user 


number 1) or as the service representative (user number 255) in order to 
use SYSLDSA. This System Service will not tolerate concurrent activity in 
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the DPCX system. All tasks must be stopped, other users signed off and 
only one host-initiated session enabled (which is used by HCF). 


10.5.2 EXAMINING DISK AND DATASET RECORDS 


Blocks on disk and dataset records at an 8100 may be inspected and 
optionally altered from the host while DPCX is operating. Use the SYSRIS 
DPCX System Service from a terminal connected via HCF. The same data may 
also be printed with the print option, and the resulting print spool 
records retrieved to the host as described in "Capturing DPCX Displayed or 
Printed Data at the Host" on page 110. (SYSRIS may also be used to inspect 
and alter diskette records). 


Note: The host user must sign on either as the DPCX control operator (user 
number 1) or as the service representative (user number 255) in order to 
use SYSRIS. | 


10.5.3 VALIDATING AND RECOVERING DISK SPACE 


A user at the host may validate the integrity of datasets and even recover 
lost disk space, subject to the constraints mentioned below. The SYSDVAR 
DPCX System Service is used for this purpose, and it also includes facili- 
ties to hash index dataset keys to member pointers, and decode bit map 
entries to disk addresses and the converse. 


Note: The host user must sign on either as the DPCX control operator (user 
number 1) or as the service representative (user number 255) in order to 
use SYSDVAR. The function which recovers disk space will not tolerate con- 
current activity in the DPCX system. All tasks must be stopped, other 
users signed off and only one host-initiated session enabled (which is 
used by HCF). 


The disk space recovery function insists on using a printer to maintain an 
audit trail. This is a tertiary printer, not spooled, and must be a 
device attached to the DPCK system. In consequence, before attempting to 
recover disk space from the host, you need to identify a DPCX printer 
which is ready with sufficient paper available. 


As recovering disk space must be preceded by validating datasets, this 
process may take several hours (the time required will increase with the 
number of disks that DPCX is using). You may conclude that these consider- 
ations make it preferable to run the disk space recovery function at the 
DPCX site. 


10.5.4 RECOVERING THE PRINT SPOOL DATASET 


A user at the host can, from a terminal signed on to HCF, invoke the DPCX 
System Service SYSSPREC to recover the print spool dataset. Use SYSSPREC 
when spool file errors are indicated at IPL or during system operation. It 
produces no output except a completion message indicating success or fail- 
ure. 
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Note: The host user must sign on either as the DPCX control operator (user 
number 1) or as the service representative (user number 255) in order to 
use SYSSPREC. This System Service will not tolerate concurrent activity in 
the DPCX system. All tasks must be stopped, other users signed off and 
only one host-initiated session enabled (which is used by HCF). 


10.5.5 DETERMINING THE STATUS OF DOSF FILES 


The DOSF System Service SYSXFEA3 may be used to obtain a summary of the 
status of the DPCX datasets used by DOSF. This program can be invoked at 
an HCF-connected terminal by a user signed on with any DPCX operator num- 
ber, and will display its output at the terminal or spool it to a PSN. The 
latter option allows the retrieval of the information to the host using 
the method of "Capturing DPCX Displayed or Printed Data at the Host" on 
page 110, but as there is only one screen image involved it is probably 
more easily read from the display terminal. 


10.6 APPLICATION PROBLEMS 


The following techniques may be of use in isolating problems in applica- 
tion software. 


10.6.1 TRACING FUNCTION PROGRAMS 


The DPCX Program Execution Monitor, accessed by the two system services 
SYSDEBUG and SYSTEST, gives a DPCX user the capability to monitor the exe- 
cution of application Function Programs (FPs). SYSDEBUG is invoked from 
the monitor terminal, and can either trace a subtask, which it will initi- 
ate for you, or programs executing on a primary device. In the latter 
case, the device is linked to SYSDEBUG by invoking the SYSTEST System Ser- 
vice from that terminal. 


The services both of SYSDEBUG and SYSTEST are available to a user at the 
host with an HCF-connected terminal. If you wish to trace a task executing 
on a primary device, you will need two HCF-connected terminals, one on 
which to run SYSDEBUG and one on which to invoke SYSTEST and the program 
to be monitored. 


When using SYSDEBUG via HCF, it is not possible to use its printing or 
screen copy facilities. These require a printer on the same control unit 
as the SYSDEBUG terminal, but DPCX cannot connect to a host-attached prin- 
ter. You may of course use device-initiated control unit local copy to 
copy display screens to an available printer. 


10.6.2 RETRIEVING FUNCTION PROGRAM ABEND DUMPS TO THE 
HOST 


Host Prep SYSINFOREF will retrieve FP ABEND dumps to the host and print 
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them there. The control statements shown in Figure 57 on page 120 will 
cause the retrieval of all dumps at the the DPCX system and delete them 
from the DPCX FP ABEND dataset. 


There is no capability to selectively print one dump, and the dump dataset 
can hold a considerable amount of dump data, so if you will need to look at 
FP ABEND dumps you should institute procedures so that the dataset is 
purged regularly with the PURGE PGMDUMP command when dumps are not 
required. Alternatively, you may prefer to purge the dataset after an 
ABEND from which you wish to see the dump. Then re-create the ABEND so the 
dump of this condition is the only one present, and then retrieve dumps to 
the host. If the dumps are neither purged nor retrieved they will eventu- 
ally fill the dataset and no more will be taken. 


Remember that IBM application software such as DISOSS is implemented as 
user FPs, and a problem involving such a product might result in the IBM 
Support Centre requesting you to print an ABEND dump. The same could hold 
true of an ABEND in a system service; System Services are also DPCX FPs. 


GENERATE SYSID(TEXTAF10) 
RETRIEVE DUMPS 
END 

b ] 


STARTCOM SYSID(TEXTAF10) 
LIST RESPONSE (ALL) SYSID(TEXTAF10) 


Figure 57. Retrieving Function Program ABEND dumps to the 
host: these control statements will retrieve all 
function program ABEND dumps from a DPCX system to the 
host. 


10.7 NETWORK PROBLEMS 


The techniques here are applicable to the network downstream of an 8100. 


10.7.1 TESTING THE DOWNSTREAM NETWORK 


The QUERY command may be used by a host user on an HCF-connected terminal 
to inspect the status of devices attached to DPCX. SYSTCM may be used in a 
similar way to run its variety of tests to DPCX devices. Neither of these 
functions produces any printout, and the information desired, if not used 
immediately, can usually be noted down easily. The response to QUERY 
DEVICES will be copious if the DPCX system has several loops and links 
configured; capturing this data would be a good candidate for control unit 
local copy from the HCF screen. Alternatively, the command could be issued 
from an operator which is being journaled and, once check-pointed, the PSN 
retrieved to the host using the technique of "Capturing DPCX Displayed or 
Printed Data at the Host" on page 110. 
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10.7.2 CONTROLLING PCA TRACES FROM THE HOST 


DPCX supports SNA protocol or data traces of its links and loops, spooling 
the traced data to a system dataset for subsequent formatting. SYSINFOREF 
contains function to allow you to control this from the host, and to 
receive and print the information there. Figure 58 and Figure 59 show 
respectively: 


e How to start PCA data and protocol traces on DPCX using SYSINFOREF 


e How to stop DPCX PCA data and protocol traces with SYSINFOREF and 
retrieve the spooled information to the host. 


This SYSINFOREF option invokes the same traces from the host as does the 
System Service SYSCOMTF on DPCX. 


GENERATE SYSID(TEXTAA10O) ; 

SEND DLADATA START DLA(81) LNG(16); 
END ; 7 
GENERATE SYSID(TEXTAB10) ; 

SEND DLAPROTOCL START DLA(10); 

END; 

STARTCOM NETWORK; 

LIST RESPONSE (ALL) ; 


SOM OMe 


Figure 58. Starting PCA protocol and data traces at DPCX 
systems: these control statements will start PCA data 
and protocol traces on respective 8100s. 


GENERATE SYSID(TEXTAA10O) ; 

SEND DLADATA STOP DLA(81); 

RETRIEVE DLADATA DLA(81) TIMEON(000001) TIMEOFF (235959); 
END; 

GENERATE SYSID(TEXTAB10) ; 

SEND DLAPROTOCL STOP DLA(10); 

RETRIEVE DLAPROTOCL TIMEON(000001) TIMEOFF (235959) ; 

END; 

STARTCOM NETWORK; 

LIST RESPONSE (CALL) ; 


SOM M SOOM yoe 


Figure 59. Stopping and retrieving PCA protocol and data 
traces: these control statements will stop PCA data and 
protocol traces on respective 8100s and retrieve the 
spooled information to the host. 


10.7.3 RETRIEVING CONTROL UNIT ERROR LOGS WITH SYSINFOREF. 


Host Prep SYSINFOREF has the capability to cause DPCX to retrieve and 
return to the host the error logs from attached 3276 or 5210 control 
units. The counters may be reset to zero. It is a good idea to institute a 
procedure to retrieve and clear the logs of all such devices regularly, 
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perhaps once a week, as a high error rate may be indicative of a 
low-quality communications link, or a loop with intermittent problems. 


The control statements in Figure 60 show how to retrieve and reset the 
error logs for one 3276 on one DPCX system. Use JCL as in Figure 61 on page 
127, and for a 5210 omit the RETRIEVE statement for TYPE(2) as this log is’ 
not used by this device. 


This SYSINFOREF option performs the same function from the host as does 
the System Service SYSRSLOG on DPCX. 


GENERATE SYSIDCTEXTAB10) ; 

RETRIEVE FIDLOG TYPE(1) STATION(0100) RESET; 
RETRIEVE FIDLOG TYPE(2) STATION(0100) RESET; 
RETRIEVE FIDLOG TYPE(3) STATION(0100) RESET; 
RETRIEVE FIDLOG TYPE(5) STATION(0100); 

END; 

STARTCOM SYSIDCTEXTAB10) ; 

LIST RESPONSE(ALL) SYSIDCTEXTAB10); 


& 
& 
& 
& 
& 
& 
& 
& 


Figure 60. Retrieving control unit error logs: these control 
statements will retrieve and reset all the control unit 
error logs for a 3276. 
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PART 4: APPENDICES 


This part of the manual should be referred to as necessary when more 
information or examples are required in relation to a topic. 
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A.O SYSINFOREF INITIALISATION AND USE 


The information in this appendix is intended to assist the user who is 
commencing work with SYSINFOREF. It is complementary to that contained in 
the Host Prep SYSINFOREF Guide and Reference which should also be con- 
sulted. 


A.1 SYSINFOREF VSAM DATASET ALLOCATIONS 


The Host Pret SYSINFOREF Guide and Reference describes the VSAM datasets 
that SYSINFOREF uses, their organisation and the AMS commands to define 
them, but it gives no guidance as to how much space to allocate. SYSINFO- 
REF uses a minimum of two datasets, BHDWK1 and BHDSSIL, in addition to 
reading from BQBLIBI. 


The BHDWK1 dataset: is where the machine list, the PTF library, the 
TEMPLIB, the generation file and the response file all reside. Its name 
is misleading; it should not be thought of as a work dataset, because the 
machine list and the PTF library comprise permanent data. If you fill this 
dataset, you should allocate a new, larger one and use AMS REPRO to copy 
the full dataset into the new one. 


Use the following guidelines to calculate the disk space required for the 
data component of the BHDWK1 dataset: 


: Allow four megabytes for the PTF TEMPLIB. 


: Allow one megabyte for the PTF library for each set of DPCX and DOSF 
software levels supported. So if you are keeping PTFs for DPCX release 
2.2, feature 6001f and DOSF release 2.1, and also for DPCX release 3.0 
and DOSF 3.0, then allow two megabytes for the PTF library. 


° Allow half a megabyte for the generation file. 

e Initially allow one megabyte per 8100 for the response file, for as 
many systems as you will contact in one execution of SYSINFOREF. This 
is particularly variable, as large amounts of disk space can be con- 
sumed by retrieving a full complement of FP ABEND dumps or all tie 
condition incident log data from all the 8100s. 

e The storage required for the machine list is negligible. 


One megabyte of storage in the BHDWK1 dataset occupies about four and a 
half cylinders of 3330 disk. 


The OS/VS version of SYSINFOREF with Host Prep release 5.0 introduces two 
additional VSAM datasets which off-load BHDWK1. The datasets are BHDWK1 
and BHDWK2, and the data which may now be stored in them, instead of in 
BHDWK1, is as follows: 

. BHDWK2 can contain the PTF TEMPLIB 

: BHDWK3 can contain the generation and response files 

Their use is not mandatory, and they are only used if available, but it is 


recommended that you do employ them. Having the truly temporary data (the 
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TEMPLIB and the generation and response files) in aepuraee datasets allows 
it to be deleted independently of the permanent library data. The advan- 
tages of this are: 


° The TEMPLIB and the generation and . response files may be deieeea by 
deleting and redefining the BHDWK2 and BHDWK3 datasets with AMS. This 
gives a significant performance improvement over SYSINFOREF deleting 
this data (which it does one VSAM record at a time), especially when 
large amounts of data are involved. 


e It is easier to adjust the storage allocation for the generation and 
response files, which depends considerably on how the network is oper- 
ated and what SYSINFOREF is being used for. BHDWK3 may simply be 
deleted and re-allocated with more space, without the need to worry 
about preserving the machine list and the PTF library. 


The BHDSSIL dataset: requires storage for each version of each applica- 
tion that resides in it, and varies according to the number of modules 
entailed and their size. IBM products may give you guidance to the amount 
of disk storage required in the memo to users which accompanies the prod- 
uct; if a figure is given for BQBLIBI, the storage needed in the data com- 
ponent of BHDSSIL will be similar. 


A.2 INITIALISING SYSINFOREF 


Before SYSINFOREF can be used to handle PTFs, it has to be identified to 
VTAM and the 8100/DPCX systems have to be identified to it. This can be 
done by coding control statements to describe the 8100s to SYSINFOREF, but 
it is easier to run the job illustrated in Figure 61 on page 127, which 
will establish a session to each DPCX/DOSF system and determine its soft- 
ware level and features. 


The first statement names the VTAM application id that the installation 
has defined for SYSINFOREF. Subsequent ones refer to the batch logical 
unit of each 8100 that is to be used for SYSINFOREF communications. These 
must be active to VTAM before running the job. The example shown is for a 
network of one test and ten production 8100s. 


Because SYSINFOREF hasn't actually been asked to do anything with these 
systems, it may print out the contents of some control blocks in antic- 
ipation of a user error. This may be ignored. The LIST MLIST statement 
will show what SYSINFOREF has found out; check that each system is repres- 
ented. The LIST RESPONSE statement will report any errors that occurred. 


When the network increases with the addition of eurenee 8100s, they may be 
defined in the same way. 


A.3 SYSINFOREF CLASSES 


The DPCX/DOSF systems should be grouped into classes for ease of opera- 
tion. Classes should be selected on the basis of including together sys- 
tems to which it is desired to make the same changes at the same time. The 
simplest method, which will suffice in many cases, is to have one class 


126 DPCX/DOSF Network Management 


//SIRFINI JOB 
//SETUP EXEC 
//STEPCAT DD 
//STEPLIB DD 
//SYSPRINT DD 
//BHDWK1 ODD 
//BHDSSIL DD 
//BQBLIBI DD 


SYS INFOREF 
PGM=BHDLMS 
DISP=SHR , DSN=vsam_user_catalog 
DISP=SHR , DSN=Host_Prep_load_library 
SYSOUT=A 
DISP=SHR , DSN=BHDWK1 
DISP=SHR , DSN=BHDSSIL 
DISP=SHR , DSN=BQBLIBI 


(if needed) 
(if needed) 


Replace these dataset 
names with those defined 
by your installation 


//SYSIN DD 
& 


alee 
wv 


DEFINE CONTROL APPLID(SIRF) : 
& STARTCOM SYSID(TESTZZ10) : 
& STARTCOM SYSID(TEXTAA10) ; 
& STARTCOM SYSID(TEXTAB10) ; 
& STARTCOM SYSID(TEXTAC10) : 
& STARTCOM SYSID(TEXTAD10) : 
& STARTCOM SYSID(TEXTAE10) : 
& STARTCOM SYSID(TEXTAF10) : 
& STARTCOM SYSID(TEXTAG10) ; 
& STARTCOM SYSID(TEXTAH10) : 
.& STARTCOM SYSID (TEXTAI10) : 
& STARTCOM SYSID(TEXTAJ10) : 
& ADD MLIST SYSID(CTESTZZ10) 
& CLASS (900) ; 
& ADD MLIST SYSID(TEXTAA10) 
& CLASS (1) : 
& ADD MLIST SYSID(TEXTAB10) 
& CLASS (1) ; 
& ADD MLIST SYSID(TEXTAC10) 
& CLASS (1) ; 
& ADD MLIST SYSID(TEXTAD10) 
& CLASS (1) : 
& ADD MLIST SYSID(TEXTAE10) 
& CLASS (1) ; 
& ADD MLIST SYSID(TEXTAF10) 
& CLASS (1) : 
& ADD MLIST SYSID(TEXTAG10) 
& CLASS (1) : 
& ADD MLIST SYSID(TEXTAH10) 
& CLASS (1) : 
& ADD MLIST SYSID(TEXTAI10) 
& CLASS (1) : 
& ADD MLIST SYSID(TEXTAJ1C) 
& CLASS (1) : 
& LIST MLIST : 
& LIST RESPONSE (ALL) ; 
/* 
// 
Figure 61. SYSINFOREF initialisation: sample JCL and control 

statements to identify SYSINFOREF to VTAM and to 


identify the DPCX/DOSF systems to SYSINFOREF. 


for the test/development machine and another for all production machines. 
Figure 61 on page 127 includes control statements which will achieve this. 
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A.4 SYSINFOREF PHASES AND TIMING OF SESSIONS 
SYSINFOREF processing is divided into four phases. They are: 


Maintenance Phase’ for updating the SYSINFOREF libraries 

Generation Phase for defining the transmissions that are required 
Communication Phase for transmitting to the DPCX/DOSF systems 
Response Phase for determining the results of these transmissions 


These are described in more detail in the introduction to the SYSINFOREF 
guide and reference. 


These phases are distinct stages of activity, which, for planned, con- 
trolled maintenance will often be separated in time. For instance 


e In the morning SYSINFOREF might to be invoked to copy PTFs retrieved 
the previous day from the TEMPLIB to the PTF library. This uses the 
maintenance phase of SYSINFOREF. 


: Once that has been achieved, SYSINFOREF generation phase could be 
invoked in the afternoon to define transmissions to production 
DPCX/DOSF systems to send and install PTFs. 


e A job might be submitted for execution overnight to perform these 
transmissions (communications phase). This is to run out of prime 
shift because there is a lot of data to be transmitted and the PTF 
install process will not tolerate any other active users. 


ad The next day SYSINFOREF would be used in the response phase to see the 
results of the transmission. 


Important Note: the generation, communication and response phases must be 
executed serially for one purpose at a time. Invoking the generation phase 
will: 


° Delete any generated data from previous executions of SYSINFOREF. 


e Delete any data generated prior to the last invocation of the communi- 
cation phase. | 


e Delete any response data. 


It is possible to have a number of generates following each other in the 
same control statement stream - all the generated data will aggregate - 
but all of it must be transmitted with the communication phase and the 
responses listed before generating more data. 


There will be times when it is needed to send (for instance, a corrective 
service PTF) to a particular 8100 as fast as possible. SYSINFOREF may 
also be used for other purposes such as initiating traces or retrieving 
trace data during the day. As stated above, each SYSINFOREF job that 
invokes the generation phase will delete any data previously generated for 
transmission and any response records, so it is no good running the gener- 
ation phase to set up scheduled maintenance to run overnight and then run- 
ning a job to generate a transmission to send an urgent PTF to an 8100. © 
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9.00 a.m. Run response phase 
for yesterday s 
transmissions 


10.00 a.m. A PTF is urgently 
needed at an 8100. 
Run all four phases 
to create it in the 
PTF library, generate 
a transmission, run 
it and list responses. 


11.00 a.m. Perform maintenance 
phase, loading PTFs 
into the library for 
transmission tonight 


2.00 p.m. A DLA link trace is 
needed at an 8100. 
SYSINFOREF is run 
several times to start, 
stop and retrieve the 


trace. 

4.00 p.m. Perform generation 
phase, defining the 
transmissions to be 
run tonight. 

5.00 p.m. A PTF is urgently 


needed at an 8100. 
However, as the over- 
night transmissions 
are already set up, 
it must wait until 
tomorrow. 


6.00 p.m. A job is released 
to execute the 
transmissions 


Figure 62. Possible scheduling of SYSINFOREF phases: care must be 
taken as the generate / communicate / response process 
works serially. 


In consequence, plan to run the generation for the overnight maintenance 
as the last task of the day. This procedure is represented by the diagram 
in Figure 62. Remember, the generate / communicate / response process is 
serial; each set of data generated must be communicated and the responses 
referenced before generating more data. 


Care must also be taken when aggregating generated data for different pur- 
poses that it does go only where it is wanted. For instance, generating a 
PTF transmission for feature DOSF21 with intent to send it to 8100A and 
generating a request to retrieve a PTF listing from 8100B, and then start- 
ing communications to each of these systems thus: 
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.& GENERATE FEATURE (DOSF21) ; 
-& SEND PTF ....... : | 
.& END; 

.& GENERATE SYSID(LU8100B) ; 
.& RETRIEVE PTF STATUS; 

.& END; 

.& STARTCOM SYSID(LU8100A) ; 
.& STARTCOM SYSID(LU8100B) ; 


would have the additional, undesired result of sending the PTF to 8100B if 
this had DOSF release 2.1. Moreover, if the same system is referenced by 
more than one STARTCOM statement, perhaps once by CLASS and once by SYSID, 
then all the generated data which is applicable to that system will be 
executed twice. Only the response records for the second set of trans- 
missiors will be available - they will have overlaid those from the first 
set. 


It is possible to run multiple copies of SYSINFOREF (see "Running Multiple 
Copies of SYSINFOREF" on page 131), so that one might be used for sched- 
uled maintenance and another for problem determination and problem resol- 
ution activities, but the complexities which this introduces in terms of 
maintaining multiple libraries and avoiding attempts to transmit concur- 
rently make this worthwhile probably only for larger networks. 


A.S5 RECOVERY OF SYSINFOREF TRANSMISSIONS 


Should a network resource be unavailable or a network component fail, or 
if the host operating system or SYSINFOREF abnormally terminates, some 
sessions may not be completed. Each transmission (that is, each matching 
of a set of generated data against an 8100) will be in one of three states: 


: Not started: either SYSINFOREF processing never reached this far, or 
the 8100 could not be contacted. 


e Completed: the failure occurred after this transmission had finished. 


° Incomplete: the transmission started, but a failure occurred while it 
was running. 


In the event of a network problem or other failure for which SYSINFOREF 
can continue processing, it will give an error message and a snap dump of 
some control blocks, indicating that a transmission failed or could not be 
started. If host software abnormally terminates, the SYSINFOREF output 
listing will indicate which transmissions were started. If a level of mul- 
ti-tasking was not requested on the STARTCOM statement, transmissions 
will take place serially, and all prior to the last will have been com- 
pleted; and if there is more than one transmission to a given 8100, all 
prior to the last one will have been completed. The status of the last 
transmissions started will be indeterminate. 


After a failure, the first thing is to list the response file - .& LIST 
RESPONSE(ALL) - if this was not done in the job which attempted the trans- 
missions. This may give some indication of the state of sessions which 
were active when a failure occurred. There are several options for retry- 
ing: , 


. Resubmit just the .& STARTCOM control statements: all transmissions 
will be retried, including those which completed successfully. 
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° If all transmissions to some 8100s were complete, submit .& STARTCOM 
control statements for the other systems: all transmissions for these 
other systems will be retried, including those which had completed 
successfully. 


e Submit control cards to regenerate data just for those sessions which 
were incomplete or not started, and transmit just to those 8100s which 
were affected: this may be quite complicated to achieve when several 
sessions were being run to a number of 8100s, and it is recommended 
that, where possible, one of the previous options is used. 


When a partially completed transmission is performed again, depending on 
the function being performed different results may be experienced on the 
second occasion. For instance, with .& SEND AMEMBER for application pro- 
duct3;, a re-transmission may encounter some entities already at DPCX from 
the first attempt and these will not be sent again. 


A.6 INTERACTIVE SYSINFOREF 


SYSINFOREF has an option to allow a single user to control it interactive- 
ly. The support allows the control statement inputs to be read from a VTAM 
3270 terminal, on which the SYSINFOREF messages will also be displayed. 
The processing of the control statements is exactly as in batch mode, and 
all. the considerations of the serial execution of the different SYSINFOREF 
phases still apply. The interactive support does have, though, the advan- 
tages of a capability to change incorrect control statements as they are 
encountered and the possibility, for instance, of browsing a chain of 
pre-requisite PTFs on the host PTF library. 


SYSINFOREF is still initialised with a batch job; the JCL is as for 
Figure 61 on page 127. The control statement shown in Figure 63 will put 
the local 3278 with logical unit name TD781305 in session with SYSINFOREF 
if it is active to VTAM and not in session with another application. 


& STARTDEV SYSID(TD781305) MODE (L) ; 


Figure 63. Using SYSINFOREF interactively: this control statement 
causes SYSINFOREF to take subsequent input from 3278 
TD781305 


A.? RUNNING MULTIPLE COPIES OF SYSINFOREF 


There is one circumstance in which the user with a small network of DPCX 
systems may want to run two copies of SYSINFOREF on the host system, and 
that is when user applications are being coded and SYSINFOREF is being 
used to transmit programs to the development 8100 for testing. This send- 
ing of test versions of programs is likely to go on throughout the day, 
and it does not want to interfere with network maintenance or problem 
determination on the production machines which also requires SYSINFOREF. 
Nor is it desirable to fill the production SYSINFOREF libraries with test 
versions of user applications. 
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In this instance a second version of SYSINFOREF can be operated by creat- 
ing second BHDWK1 and BHDSSIL datasets, and by initialising the second 
copy of SYSINFOREF to have a different VTAM APPLID and defining only the 
development machine logical unit (TESTZZ10) to it. See Figure 64 on page 
132 for an example. Care must still be taken to avoid transmitting to the 
development 8100 with both copies of SYSINFOREF at the same time, but net- 
work management can be performed for production systems while programmers 
are sending applications to this machine. 


//SIRFINI JOB SYSINFOREF 

/ /SETUP EXEC PGM=BHDLMS 

//STEPCAT DD DISP=SHR , DSN=vsam_user_catalog (if needed) 
//STEPLIB DD DISP=SHR , DSN=Host_Prep_load_library (if needed) 
//SYSPRINT DD SYSOUT=A 

//BHDWK1 DD DISP=SHR,DSN=TESTWK1 £*** Different VSAM datasets 
//BHDSSIL DD DISP=SHR,DSN=TESTSSIL *** for second SYSINFOREF 
//SYSIN DD * 

& DEFINE CONTROL APPLID(SIRF2) 

STARTCOM SYSID(TESTZZ10) 

LIST MLIST 

: LIST RESPONSE (ALL) 

/* 
// 


Figure 64. Establishing a second copy of SYSINFOREF: sample JCL 
and control statements to identify a second copy of 
SYSINFOREF to VTAM and to identify the development 
system to SYSINFOREF. 
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B.O DPCX AND SYSINFOREF PTF HANDLING CAPABILITIES 
B.1 OVERVIEW OF DPCX/DOSF PTF HANDLING 


This section briefly outlines the possible flows of PTF data between DPCX 
systems and a host system. It is to be read as background information to 
the suggested procedures that follow, and as complementary information to 
that contained in the Host Prep SYSINFOREF Guide and Reference, the DPCX 
DOSF Diagnosis Guide and the DPCX Programming Guide to Host Communication 
for System Programmers. Figure 65 on page 134 shows the possible routes 
that the PTFs can take prior to eventual installation on DPCX/DOSF. 


e Usually PTFs arrive on diskettes from IBM. 


Before release 3 of DPCX this diskette must be [PLed, and this process 
copies the PTFs to a system dataset 8. From release 3 onwards, the 
operations referred to as acting on system dataset 8 work directly 
from the diskette and system dataset 8 is not used. 


° From system dataset 8 (DPCX R3: the diskette) the PTFs may be copied 
with the DPCX SYSPTF System Service to system dataset 12, which is the 
PTF dataset. 


This process selects the PTFs applicable to the software level and 
features of the DPCX system. 


e PTFs may be installed from the PTF dataset onto the DPCX operating 
system with SYSPTF. 


For a DPCX/DOSF ASSIST installation, all the above may be done automat- 
ically. 


: SYSPTF is also able to dump PTFs to diskette from the PTF dataset. 


e PTFs from the diskette can be restored onto another DPCX system's 
dataset with SYSPTF. 


° PTFs may be retrieved to the host using SYSINFOREF. 


- An entire diskette image can be obtained from system dataset 8 
(DPCX R3: the diskette). 


—  PTFs can be taken from the PTF dataset, selectively if desired. 


In both cases they are retrieved into the SYSINFOREF temporary 
library, or TEMPLIB. 


. From the TEMPLIB, PTFs may be copied to the SYSINFOREF PTF library 
with the ADD PTF function; selection is possible. 


° Once on the SYSINFOREF PTF library, PTFs are available for sending to 
(production) DPCX systems. They are transmitted to the DPCX PTF data- 
set. 


° From the PTF dataset, PTFs may be installed onto the DPCX system with 
SYSPTF or SYSINFOREF. 
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Figure 65. DPCX and SYSINFOREF PTF flows: This figure illustrates 
the possible flows of PTF records between DPCX systems 
and a host system/3/70. 


° PTFs for corrective service may be keyed directly into the DPCX PTF 
dataset using SYSPTF. 


e They may also be defined into the SYSINFOREF PTF library at the host 
using the ADD PTF control statement. 
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B.2 COMPARISON OF SYSPTF AND SYSINFOREF PTF FUNCTIONS 


This section indicates for each option of the DPCX SYSPTF system service, 
the SYSINFOREF statements that achieve the same function. It also includes 
some description of these functions. It is provided for the benefit of 
the user who may have used SYSPTF, but is not yet familiar with SYSINFO- 
REF. 


SYSPTF OPTION: SYSINFOREF STATEMENT(S): 

1 Install PTFs .& INSTALL ALL or .& INSTALL ACTION; 
SYSPTF option installs one or all PTFs; unless the PTF is HOLD status 
SYSPTF will attempt to install it whether or not it is already installed. 
SYSPTF will report that: 


1. It installed the PTF if the target data matched the PTF verify 
data. . 


2. The PTF is already installed if the target data matches the PTF 
replace data. 


3. The PTF conflicts if the target data matches neither the verify or 

the replace data. This may arise if a subsequent PTF having this 

PTF as a prerequisite has changed the data again. 
SYSINFOREF install can either specify installation of all PTFs (that are 
not held) or just those PTFs which have an action status of install. This 
status may be assigned when the PTF is sent to DPCX, or by a subsequent .& 
UPDATE PTF(nnnnnnn) ACTIONCINSTALL) statement. 
2 Remove PTFs .& REMOVE PTF(nnnnnnn) ; 

.& INSTALL ACTION; 


SYSPTF will remove a single, named PTF from the system. It remains in the 
PTF dataset in READY status. 


SYSINFOREF will flag individual PTFs for removal; they are removed when 
the PTF install process is invoked. 


3  Dump/Restore PTFs .& RETRIEVE PTF TEXT(TEMPLIB) ; 
.& SEND PTF; | 


The SYSPTF dump/restore function can dump the PTF dataset to diskette on 
one DPCX system and restore it to the PTF dataset on other DPCX systems. 


SYSINFOREF can retrieve PTFs from the PTF dataset on one DPCX system and 
transmit them to the PTF dataset on other DPCX systems. 


4 List/Test PTF Status .& RETRIEVE PTF STATUS; and 

.& RETRIEVE PTF VERIFY; 
SYSPTF list option gives the status of PTFs as recorded in the PTF data- 
set. The test option compares the PTF verify and replace data to the tar- 


get data and reports one of the three conditions described for the install 
option: the PTF is installed, not installed or conflicts. 
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SYSINFOREF RETRIEVE PTF STATUS functions as SYSPTF list; RETRIEVE PTF VER- 
IFY functions as SYSPTF test. 


5 Copy PTFs to PTF dataset .& RETRIEVE PTF DISKETTE; 
.& SEND PTF DISKETTE; 


SYSPTF option 5 copies PTFs from the temporary dataset (8) - or for DPCX 
release 3, directly from diskette - to the PTF dataset. 


SYSINFOREF will retrieve PTFs from the temporary dataset (8) - or for DPCX 
release 3, directly from diskette - to the host. From here they may be 
sent to the PTF dataset of a DPCX system. 
6 Verify/Update PTF .& RETRIEVE PTF TEXT(RESPONSE); 
SYSPTF option 6 will display the PTF requisites and each patch unit of 
compare and replace data. It is possible to update this data if the PIF is 
not installed. 
SYSINFOREF will retrieve this information to the host. If a PTF is not 
installed it may be changed on the host and re-transmitted to DPCK - see 
the Create PTF option following. 
¢ Create PTF 7 .& ADD PIF ; 

.& SEND PTF ; 
SYSPTF option 7 allows manual entry of a PTF into the DPCX PTF dataset. 
SYSINFOREF supports manual specification of a PTF at the host site. It is 
written to the host PTF library, and may be transmitted to the PTF dataset 
on a DPCX system. 
8 Enable/Disable PTF .& UPDATE PTF ACTION(READY); and 

.& UPDATE PTF ACTION(HOLD) ; 


A PTF which is not installed may be held (disabled) by SYSPTF option 8. It 
cannot be installed until it is made ready (enabled). 


SYSINFOREF performs the same function with the control statements shown. 
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C.0 SAMPLE PROGRAMS 


This appendix contains working examples of programs employing techniques 
suggested elsewhere in this manual. 


C.1 PROGRAM TO COPY A BDES TAPE BACK TO BQBLIBI 


The sample PL/1 program which follows will read a BDES data-stream from 
tape or diskette and build a BQBLIBI dataset as output. They may then be 
copied into the SYSINFOREF BHDSSIL library in the normal way. The tech- 
nique be used to make products distributed on diskettes in BDES format 
available for distribution via the network. 


The sample program could readily be extended to handle DSCBs. 


C.1.1 SOURCE OF SAMPLE PROGRAM. 


BDEBQB: /* BDE TAPE TO BQBLIBI DATA SET */ 
[BEREREREREREEERRERERERERERRERERERE ERE BERBERS ER EEBRERRERER EEE ES 
w se 
% FUNCTION: READS BDE-FILE ESTABLISHED AT 8100 DPCX * 
* BY FDP 5798-DHX AND WRITES THE PROGRAMS * 
* AND PANELS INTO THE HOST-BQBLIBI. we 
* VERSION- AND LEVEL-SUFFIX FOR THE BQBLIBI * 
“ RECORDS IS DEFAULTED TO 00/00 IF IT IS w 
* NOT PROVIDED THRU JCL-PARM FOR THAT RUN. * 
¥ PRINTS ACTIVITY-REPORT. * 
* AUTHOR : U.KAEMPFER, WTSC RALEIGH w 
* DATE : JUNE 82 ro 
7% MANUALS REFERENCED ARE: ¥e 
* = LY38-3036 HOST PREP LOGIC (FOR BQBLIBI RECORD * 
cS LAYOUT) # 
* = §C27-0533 INSTALLING HOST-PREP FOR USE WITH OS/VS * 
¥ (FOR VSAM-DEF OF BQBLIBI) W 


nFae wnSce wal co wlan males exten enh an ntan nl as antes eater lo man wlan males ent an ales entice ex? co eal en wl ce wolace en ¥ cs tnbce mnlicr ance elas enlace alan enlace mates malice en ben en Ven onlice Van len onl es entias ent an on fan ma¥as malas tales en¥a0 on'ar enter ents enter mts enPue oalan oat eala salar 
PAY ri GV IV ED PV AGT ID IV IV GV EV ID IY AR GE IT ED EVID EH IV IH IV IV IV IDL IV GIL EL IV IV EV GD IV GL GRIT IL GL ILIV ID GV IV ED IV ER ID ER ID CD Od CL OD 
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PROC (JCLPARM) OPTIONS(MAIN) REORDER; 


DCL ABEND CHAR(50) INIT('THIS IS THE INITIAL ABEND MESSAGE TEXT'); 


ON ERROR BEGIN; 


DCL 
DCL 


DCL 


DCL 


DCL 
DCL 
DCL 
DCL 


DCL 


ON ERROR SYSTEM; 

PUT DATA; 

CALL PLIDUMP('TFSB' ,ABEND); 
END; 


(LOW ,SUBSTR,DATE,TIME,TRANSLATE) BUILTIN; 


BDETAPE FILE RECORD INPUT; 
EOF BIT(1) INIT('0'); 
ON ENDFILE(BDETAPE) BEGIN; 
EOF = '1'; 
END ; 
P POINTER: /* ALL INPUT STRUCTURES 
/* BASED ON IT 
K POINTER; /* REC-ID BUILD-UP AREA 
H POINTER; /* LEVEL IN HEX 
O POINTER; /* 256-BYTE AREA 
B POINTER; /* 1024-BYTE AREA 
PR POINTER; /* PRINT-LINE 
S POINTER; /* MH-SAVE AREA 


DCL 


DCL 
DCL 


DCL 
DCL 
DCL 


DCL 


BQBLIBI FILE RECORD OUTPUT SEQUENTIAL BUFFERED 
ENVIRONMENT(VSAM); /* IT'S A ESDS VSAM 


JCLPARM CHAR(100) VARYING; /* ONLY ACCEPTED FORMAT IS 
/* V..L.. WHERE .. = 


VERSION CHAR(2) INIT('00'); 

LEVEL  CHAR(2) INIT('00'); 

1 LEVELHEX BASED(H), 
3 LEVELFILL1 BIT(8) UNALIGNED, 
3 LEVELHEXONEBYTE BIT(8) UNALIGNED; 


LEVELHEXHW BASED(H) BIN FIXED(15,0) UNALIGNED INIT(0); 


ALLOCATE LEVELHEXHW SET(CH) ; 
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% / 


DCL 1 MH BASED (P), 

3 MHID, 
5 MHIDO1 BIT (16), 
5 MHID23 CHAR(02), 
5 MHID45 BIT (16), 


5 MHFILL1 CHAR(24), 
MHPID1 § CHAR(04), 
MHPID2 §_CHAR(04), 
MHFILL2 CHAR(86), 
MHCOUNT CHAR(04); 


to W WW 


DCL 1 PGM128IN BASED(P), 
3 PGMINP CHAR (128) ; 


DCL 1 PGM112IN BASED (P), 
3 PGMINP112 CHAR(112), 


/* INPUT STRUCTURE % / 
/* FOR MESSAGE-HEADERS * / 
/* HEX '0281' * / 
/* HEX '0000' %/ 
/* PGM HEX '0000' ve / 
/* PNL HEX '0404' # / 
/* HEX NULL * / 
/* PGM/PNL-ID * / 
/* PGM/PNL-ID % / 
/* HEX NULL % / 
/* EBCDIC COUNT OF 128 REC*/ 
/* FOLLOWING THIS MH % / 
/* (USED TO CONTROL LOOP) */ 


/* INPUT 


STRUCTURE % / 


/* FOR PGM-DATA-RECORDS */ 


/* 
/* INPUT 


128 BYTES OF PGM-DATA */ 


STRUCTURE */ 
112 BYTES OF PGM-DATA */ 


Le 
3 PGMINPBLKCNT BIN FIXED(15,0) UNALIGNED; 


DCL 1 PNL112IN BASED (P), 
3 PNLINP112 CHAR(112), 
3 PNLINPFILL1 CHAR(001), 


/ ofa 
cA 


/* INPUT 
/ . 
/ ve 


IN THE FIRST REC ONLY */ 


3 PNLINPHEXID BIN FIXED(15,0) UNALIGNED; 


DCL 1 SMH BASED (S), 
3 SMHID, 

5 SMHIDO1 BIT (16), 

5 SMHID23 CHAR(02), 

5 SMHID45 BIT (16), 


5 SMHFILL1 CHAR(24), 
SMHPID1 CHAR(04), 
SMHPID2  CHAR(04), 
SMHFILL2 CHAR(86), 
SMHCOUNT  CHAR(04); 


WW W 


ALLOCATE SMH SET (S); 

DCL SMHSTRING CHAR(128) BASED (Ss); 
DCL SMHCOUNTBIN BIN FIXED(15,0); 
DCL SMHPNLIDHEX BIN FIXED(15,0); 


/* STORE 
/ ve 


— —- 0% - . 


oh 


> —. —- 


/* (USED 
/* (USED 


STRUCTURE * / 
112 BYTES OF PNL-DATA */ 
1 BYTE FILLER % / 

STRUCTURE % / 
FOR THE MESSAGE-HEADER */ 
* HEX '0281' % / 
* HEX ‘0000' % / 
* PGM HEX '0000' % / 
* PNL HEX '0404' we / 
* HEX NULL ¥ / 
* PGM/PNL-ID % / 
* PGM/PNL/ID % / 
* HEX NULL ¥ / 
* EBCDIC COUNT OF 128 REC*/ 
* FOLLOWING THIS MH % / 


TO CONTROL LOOP) */ 
FOR COMPARE ) */ 
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DCL 1 BQBKEY BASED (K), 
| 3 BQBKEYCC 

3 BOQBKEYIN 

3 BOBKEYFPPN 


BQBKEYV 
BOBKEYFILL1 
BOBKEYL 
BOBKEYSEQ 
BOBKEYFLAG, 


WWW WW 


/*SEE MANUAL LY38-3036 */ 


- CHAR(02) INIT('CC'), /*PAGE 8 % / 
CHAR(02) INIT('IN'), /* IN FACT, IT IS A % / 
CHAR(08), /* REC-ID RATHER THAN * / 

/* A KEY, SINCE IT IS */ 
/* A ESDS * / 


BIN FIXED (15,0) UNALIGNED, 
CHAR(1) INIT(LOW(1)), 

BIN FIXED (15,0) UNALIGNED, 
BIN FIXED(15,0) UNALIGNED, 


5 BQBKEYFLAGO BIT(1) UNALIGNED, 
5 BQBKEYFLAG1 BIT(1) UNALIGNED, 
5 BQBKEYFILL BIT(6) INIT('000000'B) UNALIGNED; 


DCL 1 BQBKEYW BASED (K) CHAR(20); 


DCL 1 BQBPRM 
BQBPRMKEY 

BQBPRMTYPE 
BQBPRMFILL1 


BQBPRMFILL2 
BQBPRMCOUNT 
BQBPRMFILL3 
BQBPRMDATE 


W WWW WW WH We 


3 BQBPRMFILL4 


DCL 1 PGM2560UT BASED(O), 
3 PGMFIRST128 


PGMBLKCNT B 


WW © WW 


PGMLEVEL 
PGMFILL1 
DCL 1 PNL2560UT BASED(0), 
3 PNLFIRST128 
3 PNLBYTES128_ 
3 
3 PNLIDHEX B 
3 PNLFILL2 


DCL PGM2560UTSTRING BASED 


ALLOCATE PGM2560UTSTRING 


PGMBYTES128_ 


/* PARAMETER RECORD*/ 
CHAR(20), /* IN BQBLIBI * / 
BIT(16), 
CHAR(24) INIT(LOW(24)), 


BOBPRMPGPNID CHAR(08), 


CHAR(148) INIT(LOW(148)), 

BIN FIXED(15,0) UNALIGNED, 

CHAR(4) INIT(LOW(4)), 

CHAR(8) 
INIT(TRANSLATE('MO/DA/YE' ,DATE, 'YEMODA')), 
CHAR(56) INIT(LOW(56)); 


/* OUTPUT BUILD-UP AREA */ 
CHAR(128), /** FOR PROGRAM-RECORDS */ 
240 CHAR(112), 
IN FIXED(15,0) UNALIGNED, 


PGMVERSION BIN FIXED(15,0) UNALIGNED, 
BIT(8) UNALIGNED, 
CHAR(11) INIT(LOW(11)); 


/* OUTPUT BUILD-UP AREA */ 
CHAR (128), /* FPR PANEL-RECORDS te / 
240 CHAR(112), 


PNLFILL1 CHAR (1), 


IN FIXED(15,0) UNALIGNED, 


CHAR(13); 


(0) CHAR(256); 


SET(O) ; 


/* THE FOLLOWING IS THE PROGRAM-CONTROLLED BLOCKING MECHANISM */ 


DCL BLOCK1 CHAR(0276) BASED(B) ; /*USED FOR PHYSICAL WRITE */ 


DCL BLOCK2 CHAR(0532) BASED(B) ; /*USED FOR PHYSICAL WRITE */ 


DCL BLOCK3 CHAR(0788) BAS 
DCL BLOCK4 CHAR(1044) BAS 


DCL 1 BLOCKTAB BASED(B), 
3 BLOCKKEY 


ED(B); /*USED FOR PHYSICAL WRITE */ 
ED(B) ; /*USED FOR PHYSICAL WRITE */ 


CHAR(20), 


3 TABBLOCK (4) CHAR(256); /* USED TO LOGICAL WRITE IN*/ 
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DCL I BIN FIXED(15,0); /* INDEX FOR BLOCKING * / 


ALLOCATE BLOCK4 SET(B) ; 


DCL CNTTOTBDE BIN FIXED (15,0) /* TOTAL BDE REC READ */ 

INIT(-1); 

DCL CNTTOTBDEINV BIN FIXED (15,0) /* TOTAL INVALID BDE REC */ 
INIT(00); 

DCL CNTPGMBDE BIN FIXED (15,0) /* BDE REC READ PER PGM/PN*/ 
INIT(00); 

DCL CNTMHBDE BIN FIXED (15,0) /* TOTAL VALID MH REC READ*/ 
INIT(0O); 

DCL CNTPGMBQB BIN FIXED (15,0) /* 240 REC WRITTEN PGM/PN*/ 
INIT(00); 

DCL CNTTOTBQB BIN FIXED (15,0) /* 240 REC WRITTEN TOTAL */ 
INIT(00); 

DCL CNTPRMBQB BIN FIXED (15,0) /** 272 PARM-REC WRITTEN */ 
INIT(00); 

DCL CNTTOTBQBPH BIN FIXED (15,0) /* 1044 REC WRITTEN TOTAL */ 
INIT(00); 
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DCL MESSAGE CHAR(120) INIT(''); 
DCL 1 LINE BASED (PR), 
3 ASA CHAR(1) INIT(' '‘), 
3 LINE120 CHAR(120) INIT(''); 
ALLOCATE LINE SET (PR); 


DCL PCNTPGMBDE PIC'ZZZ9' 
DCL PCNTPGMBQB PIC’ ZZZ9 ' 


/* CHECKING OF JCL-PARM FOLLOWS : 
IF SUBSTR(JCLPARM,1,1) = 'V' & 


(SUBSTR(JCLPARM,2,1) >='0' & SUBSTR(JCLPARM,2,1) <=' 
(SUBSTR(JCLPARM,3,1) >='0' & SUBSTR(JCLPARM,3,1) <=' 
SUBSTR(JCLPARM,4,1) = 'L' & | | 
(SUBSTR(JCLPARM,5,1) >='0' & SUBSTR(JCLPARM,5,1) <=' 
(SUBSTR(JCLPARM,6,1) >='0' & SUBSTR(JCLPARM,6,1) <=' 
THEN DO; 
"VERSION = SUBSTR(JCLPARM,2,2); 
LEVEL = SUBSTR(JCLPARM,5,2); 
LEVELHEXHW = LEVEL; 
END; 
ELSE DO; 


LINE120 = 'VERSION/LEVEL INVALID OR NOT ENTERED' | | 
' THRU JCL-PARM. DEFAULTED TO 00/00'; 
CALL PRINT(PR); 
END; 
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READ FILE(BDETAPE) SET (P); /** READ THE VERY FIRST TAPE REC */ 
CNTTOTBDE = CNTTOTBDE +1; 
ALLOCATE BQBKEY SET (K); 


' 


MAINLOOP: 

DO WHILE (EOF); /* AS LONG AS THERE ARE TAPE REC*/ 
/* CHECK IF IT Is A MESSAGE- HEADER - RECORD FOR PROGRAMS * / 
IF MHIDO1 = '0000001010000001'B /* HEX '0281' * / 

& MHID23 = LOW(2) 

& MHID45 = '0000000000000000'B 

& MHFILL1 = LOW(24) 
& MHPID1 = MHPID2 /* PGMID TWICE */ 
/* AS REQUIRED ? */ 

& MHFILL2 = LOW(86) 
THEN DO; /* IT IS A PGM-MH*/ 
SMH = MH; /* SAVE MH  / 


ON CONVERSION BEGIN; 

MESSAGE = ‘INVALID BLOCK-COUNT IN MH. aie 

" PROCESSING CONTINUES WITH NEXT MH’ 

GO TO PGMADMIT; 
END ; 
SMHCOUNTBIN = SMHCOUNT; /*AVOID CONVERSION* / 
ON CONVERSION BEGIN; 

ABEND = 'CONVERSION'; 

SIGNAL ERROR; 


END; 

BQBKEYFPPN = 'INFP'||SMHPID1; /*BUILD REC-ID */ 
BQBKEYV = VERSION; 
BQBKEYL = LEVEL; 
BQBKEYSEQ = 0; 
BQBKEYFLAGO = '1'B; /*NOT LAST RECORD*/ 
BQBKEYFLAG1 = 1'B; /**PARAMETER REC */ 
BQBPRMTYPE = '0000000000000000'B; #=/* BUILD PARM REC*/ 


BQBPRMPGPNID = SMHPID1||SMHPID2; 
BQBPRMCOUNT = (SMHCOUNTBIN / 2); 
IF SMHCOUNTBIN s= (BQBPRMCOUNT * 2) 
THEN DO; 
MESSAGE = 'BLOCK-COUNT IN MH NOT AN an 
"EVEN NUMBER. PROCESSING ' | | 
"CONTINUES WITH NEXT MH'; 
GO TO PGMADMIT; 
END; 
BQBPRMKEY = BQBKEYW; 


WRITE FILE(BQBLIBI) FROM(BQBPRM) ; /* WRITE PARM-REC*/ 
CNIMHBDE = CNTMHBDE +1; 
CNTPRMBQB = CNTPRMBOB +1; 


READ FILE(BDETAPE) SET (P); /* READ 1ST DATA REC */ 
CNITOTBDE = CNTTOTBDE +1; 
CNTPGMBDE =1; 
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/* START BUILD-UP OF FIRST 1044-BYTE BLOCK we / 


BQBKEYSEQ = BQBKEYSEQ +1; /** BUILD BLOCK-ID #/ 
BQBKEYFLAG1 = 'O'B; 

PGMFIRST128 = PGMINP; __/*BUILD FIRST HALF OF REC*/ 
READ FILE(BDETAPE) SET (P); /* READ 2ND DATA REC */ 


CNITOTBDE = CNTTOTBDE +1; 

CNTPGMBDE = CNTPGMBDE +1; 

PGMBYTES128_240 = PGMINP112; /*BUILD 2ND HALF OF REC */ 
PGMBLKCNT = PGMINPBLKCNT; 

IF PGMBLKCNT == BQBPRMCOUNT 


THEN DO; 
MESSAGE = 'MH-COUNT AND SIRST BLOCK COUNT’ | | 
' DONT MATCH ' 
GO TO PGMADMIT ; 
END ; 


PGMVERSION = VERSION; 
PGMLEVEL = LEVELHEXONEBYTE ; 
I= 1; 


TABBLOCK(I) = PGM2560UTSTRING;/* LOGICAL WRITE 1. REC */ 
CNTPGMBQB =I; /* OF BLOCK =) 


READ FILE(BDETAPE) SET (P); /* READ NEXT DATA REC ¥*/ 

CNTTOTBDE = CNTTOTBDE +1; 

CNTPGMBDE = CNTPGMBDE +1; 

DO WHILE(~ EOF & (CNTPGMBDE => SMHCOUNTBIN) & (I < 4)); 
/* AS LONG AS THE REC PERTAINS TO THE SAME PROGRAM */ 
/* AND THE OUTPUT-BLOCK ISN'T FILLED YET we / 

PGMFIRST128 = PGMINP; /*BUILD FIRST HALF OF REC*/ 
READ FILE(BDETAPE) SET (P); /*READ NEXT DATA REG * / 
CNTTOTBDE = CNTTOTBDE +1; 

CNTPGMBDE = CNTPGMBDE +1; 

PGMBYTES128_240 = PGMINP112; /*BUILD 2ND HALF */ 
PGMBLKCNT = 0; 

PGMVERSION = 0; 

PGMLEVEL = "90000000' B; 

I = I+1; 


TABBLOCK(I) = PGM256OUTSTRING; /* WRITE LOGICAL */ 
CNTPGMBQB = CNTPGMBQB +1; 


READ FILE(BDETAPE) SET (P); /* READ NEXT DATAREC */ 
CNTITOTBDE = CNTTOTBDE +1; 
CNTPGMBDE = CNTPGMBDE +1; 
END; 
IF (CNTPGMBDE > SMHCOUNTBIN) | EOF 
THEN DO; _{* LAST REC OF THIS PGM*/ 
BQBKEYFLAGO = 'O'B; 
END; 
BLOCKKEY = BQBKEYW; 
SELECT (I); /* WRITE PHYSICAL BLOCK */ 
WHEN(1) DO; 
WRITE FILE(BQBLIBI) FROM(BLOCK1); 
END; 
WHEN(2) DO; 
WRITE FILE(BQBLIBI) FROM(BLOCK2) ; 
END; 
WHEN(3) DO; 
WRITE FILE(BQBLIBI) FROM(BLOCK3) ; 
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END; 

WHEN(4) DO; 

WRITE FILE(BQBLIBI) FROM(BLOCK4) ; 
END; 
END; 
CNTTOTBQBPH = CNTTOTBQBPH +1; 


/* END OF FIRST 1044-BYTE BLOCK */ 
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/* START FURTHER 1044-BYTE BLOCKS %* / 


DO WHILE(+ EOF & (CNTPGMBDE => SMHCOUNTBIN)); 
/* AS LONG AS THE REC PERTAINS TO THE SAME PROGRAM */ 


BQBKEYSEQ = BQBKEYSEQ +1; /*BUILD BLOCK-ID % / 

I = QO; 

DO WHILE(7-EOF & (CNTPGMBDE -> SMHCOUNTBIN) & (I < 4)); 
/* AS LONG AS THE REC PERTAINS TO THE SAME PROGRAM*/ 
/* AND THE OUTPUT-BLOCK ISN'T FILLED YET # / 

PGMFIRST128 = PGMINP; /*BUILD FIRST HALF OF REC*/ 
READ FILE(BDETAPE) SET (P); /* READ NEXT DATA REC*/ 
CNTTOTBDE = CNTTOTBDE +1; 

CNTPGMBDE = CNTPGMBDE +1; 

PGMBYTES128_240 = PGMINP112; /*BUILD 2ND HALF */ 
PGMBLKCNT = 0; 

PGMVERSION = 0; 

PGMLEVEL = '00000000'B; 

I = I+1; 


TABBLOCK(I) = PGM2560UTSTRING;/* WRITE LOGICAL */ 
CNTPGMBQB = CNTPGMBQB +1; 


READ FILE(BDETAPE) SET (P); /* READ NEXT DATA REC*/ 
CNTTOTBDE = CNTTOTBDE +1; 
CNTPGMBDE = CNTPGMBDE +1; 


END; 
IF (CNTPGMBDE > SMHCOUNTBIN) | EOF 
THEN DO; /* LAST REC OF THIS PGM*/ 
BQBKEYFLAGO = 'O'B; 
END; | 
BLOCKKEY = BQBKEYW; 
SELECT(I); /* WRITE PHYSICAL BLOCK */ 


WHEN(1) DO; 
WRITE FILE(BQBLIBI) FROM(BLOCK1); 
END; 
WHEN(2) DO; 
WRITE FILE(BQBLIBI) FROM(BLOCK2); 
END; 
WHEN(3) DO; 
WRITE FILE(BQBLIBI) FROM(BLOCK3) ; 
END; 
WHEN(4) DO; 
WRITE FILE(BQBLIBI) FROM(BLOCK4); 
END; 
END; 
CNTTOTBQBPH = CNTTOTBQBPH +1; 
END; 


/* END FURTHER 1044-BYTES BLOCKS **/ 
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LINE120 = 'RECORD TOTALS FOR PGM '||SMHPID1||' :'; 

ASA = '0'; 

CALL PRINT(PR); 

PCNIPGMBDE = CNTPGMBDE; 

PCNTPGMBQB = CNTPGMBQB; 

LINE120 = PCNTPGMBDE||' BDE-TAPE REC READ (128 BYTES)']|| 
' AND '||PCNTPGMBQB||' LOGICAL BQBLIBI REC WRITTEN '| | 
'(240 BYTES)'; | 

CALL PRINT(PR); 

IF CNTPGMBQB ~= (SMHCOUNTBIN / 2) 


THEN DO; /* NUMBER OF 128-BYTE-REC IN MH HAS TO*/ 

/* MATCH ACTUAL NUMBER OF RECORDS we / 

LINE120 = ‘shivers SOMETHING WENT WRONG *! ; 
ASA ='.', | 


» 
CALL PRINT(PR); 
PCNTPGMBDE = SMHCOUNTBIN; 
PCNTPGMBQB = CNTPGMBQB; 
LINE120 = 'SECTOR COUNT IN INPUT MH :'||PCNTPGMBDE 
| RECORD COUNT IN OUTPUT _ :'||PCNTPGMBQB; 
CALL PRINT(PR); 
LINE120 = 'PROCESSING UNS UCCESSFUL'; 
CALL PRINT(PR); 
/* BACKOUT GOES HERE IF APPROPRIATE —Witvededevededevev / 
END; 
ELSE DO; 
LINE120 = 'PROCESSING FOR PGM '||SMHPID1| | 
' SUCESSFULLY COMPLETED’ ; 
CALL PRINT(PR); 
CNITOTBQB = CNTTOTBQB + CNTPGMBQB; 
END; | 
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PGMADMIT: 


PGMADMITEND: END; 
END; /* END IF-THEN PGM-MH OK*/ 
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/* ADMIT SECTION — | se) 
GO TO PGMADMITEND; — | /* SKIP AROUND IT */ 


/* INVOKED IF INPUT ERRORS DETECTED * / 


LINE120 = THRACE EEE |e 
ASA. ="'0"s 
CALL PRINT(PR) ; 
LINE120 = MESSAGE; 
CALL PRINT(PR) ; 
LINE120 = 'INPUT MH(B 1-64): ‘'||SUBSTR(SMHSTRING,1,64); 
CALL PRINT(PR) ; 
LINE120 =' (B 65-128): '||SUBSTR(SMHSTRING, 65,64); 
CALL PRINT(PR) ; 
LINE120 = '20 BYTES BQBLIBIKEY: ‘| |BQBKEYW| | 
' USED VERSION: ‘| |VERSION| | 
' USED LEVEL : ‘| |LEVEL; 
CALL PRINT(PR); 
LINE120 = TPedede ere Te TT UTE EEE EE EEE EIT 
CALL PRINT(PR); 
READ FILE(BDETAPE) SET (P); 
CNTTOTBDEINV = CNTTOTBDEINV +1; 
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ELSE DO; /* SEE IF PANEL MH */ 
/* CHECK IF IT IS A MESSAGE-HEADER-RECORD FOR PANELS */ 


IF MHIDO1 = '0000001010000001'B /* HEX '0281' / 
& MHID23 = LOW(2) 
& MHID45 = '0000010000000100'B /* HEX '0404' we / 
& MHFILL1 = LOW(24) 
& MHPID1 = MHPID2 /* PNLID TWICE ? */ 
& MHFILL2 = LOW(86) 
THEN DO; /* IT IS A PNL-MH*/ 
SMH = MH; /* SAVE MH te / 


ON CONVERSION BEGIN; 
MESSAGE = 'INVALID BLOCK-COUNT IN MH.' | | 
' PROCESSING CONTINUES WITH NEXT MH'; 
GO TO PNLADMIT; 
END; 
SMHCOUNTBIN = SMHCOUNT; /*AVOID CONVERS ION* / 
ON CONVERSION BEGIN; 
MESSAGE = 'INVALID PANEL-IDUNT IN MH.' | | 
' PROCESSING CONTINUES WITH NEXT MH'; 
GO TO PNLADMIT; 
END ; 
SMHPNLIDHEX = SMHPID1; /*FOR COMPARE ¥ / 
ON CONVERSION BEGIN; 
ABEND = 'CONVERSION' ; 
SIGNAL ERROR; 
END; 


BQBKEYFPPN = 'INPN'||SMHPID1; /*BUILD REC-ID */ 
BQBKEYV = VERSION; 
BQBKEYL = LEVEL; 
BQBKEYSEQ = 0; 
BQBKEYFLAGO 
BQBKEYFLAG1 


Bs /*NOT LAST RECORD*/ 
'1'B; /*PARAMETER REC */ 


BQBPRMTYPE = '0000010000000100'B;/*BUILD PARM REC*/ 
BQBPRMPGPNID = SMHPID1||SMHPID2; 
BQBPRMCOUNT = (SMHCOUNTBIN / 2); 
IF SMHCOUNTBIN 7-= (BQBPRMCOUNT * 2) 
THEN DO; 
MESSAGE = 'BLOCK-COUNT IN MH NOT AN ‘|| 
"EVEN NUMBER. PROCESSING ' | | 
"CONTINUES WITH NEXT MH'; 
GO TO PNLADMIT; 
END; 
BQBPRMKEY = BQBKEYVW; 


WRITE FILE(BQBLIBI) FROM(BQBPRM); /* PARM-REC */ 
CNTPRMBQB = CNTPRMBQB +1; 
CNTMHBDE = CNTMHBDE +1; 
READ FILE(BDETAPE) SET (P); 
CNTTOTBDE = CNTTOTBDE +1; 
CNTPGMBDE =1; 
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/* START FIRST 1044-BYTE-BLOCK */ 


BOBKEYSEQ = BQBKEYSEQ +1; /*BUILD REC-ID % / 
BQBKEYFLAG1 = '0'B; | 


PNLFIRST128 = PGMINP; /*BUILD FIRST HALF OF REC*/ 
READ FILE(BDETAPE) SET (P); 
CNTTOTBDE = CNTTOTBDE +1; 
CNTPGMBDE = CNTPGMBDE +1; 
IF PNLINPHEXID 7= SMHPNLIDHEX 
THEN DO; 
MESSAGE = 'MH-PANELID AND FIRST-BLOCK ID ‘|| 
'" DONT MATCH’; 
GO TO PNLADMIT; 
END; 
PNLBYTES128_240 = PGMINP112; /*BUILD 2ND HALF REC*/ 
/* INCL DATA LENGTH */ 


PNLFILL1 = LOW(1); 
PNLIDHEX = PNLINPHEXID; 
PNLFILL2 = LOW(13); 

I= 1; 


TABBLOCK(I) = PGM2560UTSTRING;/*WRITE LOGICAL 1ST*/ 
CNTPGMBQB =i; 


READ FILE(BDETAPE) SET (P); 

CNTTOTBDE = CNTTOTBDE +1; 

CNTPGMBDE = CNTPGMBDE +1; 

DO WHILE(7 EOF & (CNTPGMBDE -> SMHCOUNTBIN) 

& (I < 4)); 

PNLFIRST128 = PGMINP; /*BUILD 1ST HALF OF REC*/ 
READ FILE(BDETAPE) SET (P); 
CNTTOTBDE = CNTTOTBDE +1; 
CNTPGMBDE = CNTPGMBDE +1; 
PNLBYTES128_240 = PGMINP112; /*BUILD 2ND HALF */ 
PNLIDHEX = 0; 
I= I+1; 


TABBLOCK(I) = PGM2560UTSTRING; /** WRITE LOGICAL*/ 
CNTPGMBQB = CNTPGMBQB +1; 


READ FILE(BDETAPE) SET (P); 


CNTTOTBDE = CNTTOTBDE +1; 
CNTPGMBDE = CNTPGMBDE +1; 
END; 
IF (CNTPGMBDE > SMHCOUNTBIN) | EOF 
THEN DO; /* LAST REC OF THIS PNL*/ 
BQBKEYFLAGO = '0O'B; 
END; 
BLOCKKEY = BQBKEYW; 
SELECT(I); /* WRITE PHYSICAL BLOCK */ 


WHEN(1) DO; 

WRITE FILE(BQBLIBI) FROM(BLOCK1) ; 
END; 
WHEN(2) DO; 

WRITE FILE(BQBLIBI) FROM(BLOCK2) ; 
END; 
WHEN(3) DO; 

WRITE FILE(BQBLIBI) FROM(BLOCK3) ; 
END; 
WHEN(4) DO; 
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WRITE FILE(BQBLIBI) FROM(BLOCK4); 
END; 
END; 

CNTTOTBQBPH = CNTTOTBQBPH +1; 


/* END FIRST 1044-BYTE-BLOCK */ 
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/* START FURTHER 1044-BYTE BLOCKS */ 


DO WHILE(~ EOF & (CNTPGMBDE -> SMHCOUNTBIN)); 


/* AS LONG AS IT IS THE SAME PANEL * / 
BQBKEYSEQ = BQBKEYSEQ +1; /*BUILD REC-ID * / 
I = 0; 
DO WHILE(*EOF & (CNTPGMBDE 7-> SMHCOUNTBIN) 
& (I < 4)); 
/* AS LONG AS IT IS THE SAME PANEL ve / 
/* AND FITS IN THE SAME BLOCK we / 


PNLFIRST128 = PGMINP; 

/*BUILD FIRST HALF OF REC*/ 
READ FILE(BDETAPE) SET (P); 
CNTTOTBDE = CNTTOTBDE +1; 
CNTPGMBDE = CNTPGMBDE +1; 
PNLBYTES128_240 = PGMINP112; 

/*BUILD 2ND HALF */ 

PNLIDHEX = 0; 
I = I+1; 


TABBLOCK(I) = PGM2560UTSTRING; 


/* WRITE LOGICAL */ 
CNTPGMBQB = CNTPGMBQB +1; 


READ FILE(BDETAPE) SET (P); 
CNTTOTBDE = CNTITOTBDE +1; 
CNTPGMBDE = CNTPGMBDE +1; 


END; 
IF (CNTPGMBDE > SMHCOUNTBIN) | EOF 
THEN DO; /* LAST REC OF THIS PNL*/ 
BQBKEYFLAGO = '0O'B; 
END; 
BLOCKKEY = BQBKEYW; 
SELECT(I); /* WRITE PHYSICAL BLOCK */ 


WHEN(1) DO; 

WRITE FILE(BQBLIBI) FROM(BLOCK1); 
END; 
WHEN(2) DO; 

WRITE FILE(BQBLIBI) FROM(BLOCK2) ; 
END ; 
WHEN(3) DO; 

WRITE FILE(BQBLIBI) FROM(BLOCK3) ; 
END; 
WHEN(4) DO; 
WRITE FILE(BQBLIBI) FROM(BLOCK4) ; 
END; 
END ; 
CNTTOTBQBPH = CNTTOTBQBPH +1; 
END; 


/* END FURTHER 1044-BYTE-BLOCKS */ 
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LINE120 = 'RECORD TOTALS FOR PNL ‘||SMHPID1||' :'; 
ASA = '0'; 
CALL PRINT(PR); 
PCNTPGMBDE = CNTPGMBDE; 
PCNTPGMBQB = CNTPGMBQB; 
LINE120 = PCNTPGMBDE||' BDE-TAPE R READ (128 B)'|| 
' AND ' | |PCNTPGMBQB | | ' LOGICAL BQBLIBI REC ‘|| 
' WRITTEN (240 BYTES) ; 
CALL PRINT(PR); 
IF CNTPGMBQB -= (SMHCOUNTBIN / 2) 
THEN DO; 
LINE120 = [svete SOMETHING WENT WRONG %%'; 
ASA ='-'; 
CALL PRINT(PR) ; 
PCNTPGMBDE = SMHCOUNTBIN; 
PCNTPGMBQB = CNTPGMBQB; 
LINE120 = ‘SEC CNT IN INPUT MH :'||PCNTPGMBDE 
REC CNT IN OUTPUT _ :'||PCNTPGMBQB; 
CALL PRINT(PR); 
LINE120 = 'PROCESS UNS UCCESSFUL'; 
CALL PRINT(PR); 
/* HERE SOME BACKOUT SHOULD BE DONE *isveveveverere / 
END; 
ELSE DO; 
LINE120 = ‘PROCESSING FOR PNL '||SMHPID1| | 
' SUCESSFULLY COMPLETED' ; 
CALL PRINT(PR); 
CNTTOTBQB = CNTTOTBQB + CNTPGMBQB; 
END; 
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/* ADMIT SECTION wy 


GO TO PNLADMITEND ; /* SKIP AROUND IT */ 
PNLADMIT: DO; /*INVOKED IF INPUT ERRORS DETECTED */ 
LINE120 = Bee 
ASA = '0'; 


CALL PRINT(PR); 
LINE120 = MESSAGE; 
CALL PRINT(PR); 
LINE120 = ‘INPUT MH(B 1-64): ‘|| 
SUBSTR(SMHSTRING, 1,64); 
CALL PRINT(PR); 
LINE120 = ' (B 65-128): '|| 
| SUBSTR(SMHSTRING, 65,64); 
CALL PRINT(PR); 


LINE120 = '20 BYTES BQBLIBIKEY: '||BQBKEYW] | 
' USED VERSION: '||VERSION| | 
' USED LEVEL : '||LEVEL; 
CALL PRINT(PR) ; 
LINE120 = U elevevevedededevevedeWeese RNIN IRIE | 6 


3 


CALL PRINT(PR); 
READ FILE(BDETAPE) SET (P); 
CNTTOTBDEINV = CNTTOTBDEINV +1; 


PNLADMITEND: END; 
END; /* END IF-THEN PNL-MH OK*/ 
ELSE DO; /* INVALID INPUT (MH) % / 
LINE120 = 'INVALID INPUT READ WHERE PGM OR' | | 
: PNL MH EXPECTED HAMANN EERIE | 
CALL PRINT(PR); 
LINE120 = ‘INPUT (B 1-64): '||SUBSTR(PGMINP,1,64); 
CALL PRINT(PR); 
LINE120 =' (B 65-128): '||SUBSTR(PGMINP,65,64); 
CALL PRINT(PR); ; 7 
LINE120 = 'READING CONTINUES UNTIL VALID’ | | 
' MH FOUND OR EOF REACHED’ ; 
CALL PRINT(PR); 
READ FILE(BDETAPE) SET (P); 
CNTTOTBDEINV = CNITOTBDEINV +1; 
END; /* END INVALID INPUT % / 
END; | /* END IF-ELSE PGM-MH OK*/ 


__ END MAINLOOP; 
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LINE120 = ' TOTALS FOR THIS RUN :'; 

ASA = '1'; 

CALL PRINT(PR); 

PCNTPGMBDE = CNTTOTBDE; 

PCNTPGMBQB = CNTTOTBQB; 

LINE120 = PCNTPGMBDE||' TOTAL BDE-TAPE REC READ (128 BYTES)' | | 
' AND oer TOTAL LOGICAL BQBLIBI REC WRITTEN '| | 
"(240 BYTES)’ 

ASA = '0' 

CALL PRINT(PR) ; 

PCNTPGMBDE = CNTMHBDE; 

PCNTPGMBQB = CNTTOTBQBPH; 

LINE120 = PCNTPGMBDE||' TOTAL VALID MH REC READ' | | 
' AND oe TOTAL PHYSICAL BQBLIBI REC WRITTEN ' || 
"(1044 BYTES)’ 

ASA = =O" 

CALL PRINT (PR) ; 

PCNTPGMBQB = CNTPRMBQB; 

LINE120 = PCNTPGMBQB | | TOTAL BQBLIBI PARM REC WRITTEN (272 B)' 

ASK: =. "0" 

CALE PRINT(PR) ; 

PCNTPGMBDE = CNTTOTBDEINV; 

LINE120 = PCNTPGMBDE||' TOTAL INVALID MH REC READ'; 

ASA = '0'; 

CALL PRINT (PR); 
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PRINT: PROC(POINTPR) REORDER; 


FV GV ED GD EE ED AL GD AE AR AE IR AD GE AD AE EE IR GR AR AE ER CD GR AR AS GE EE CD FS AR OD OO AR AD ER AR CR OD ER CR ER CD EL CR FD ID EDEL ED ER ED ED CD SD ED CD CD FD OD 


ate ole 
a ee 


* THIS ROUTINE DOES ALL THE PRINTING WORK FOR THE FILE * 
* CALLED *LISTING*. EACH TIME IT IS INVOKED, A 121 CHAR * 
* PRINT LINE (INCLUDING ASA CHARACTER) IS PASSED AS A 

*% PARAMETER. IT KEEPS CONTROL OF OVERFLOW ETC. 


DCL LISTING FILE RECORD OUTPUT; 


DCL 1 OVFLL1 STATIC, 
3 OVFLASA CHAR(1) INIT('1'), 
3 OVFLLITXT  CHAR(112), 
3 OVFLITXTP CHAR(5) INIT('PAGE'), 
3 OVFL1PGE PIC'ZZ9' INIT ('000'); 
DCL 1 OVFLL2 STATIC CHAR(121) INIT('-'); 
DCL LINECNT BIN FIXED(15,0) STATIC INIT(999); 
DCL POINTPR POINTER; 
DCL PRINTLINE BASED (POINTPR) CHAR(121); 


IF (LINECNT > 55) | (SUBSTR(PRINTLINE,1,1) = '1') 
THEN DO; 
OVFLLITXT = BDE - FORMATTED TAPE TO HOST! | | 
'-BQBLIBI "| 
TRANSLATE (' MO/DA/YE' ,DATE, 'YEMODA' ) | | 


TRANSLATE('HO.MI.SE',TIME, 'HOMISE'); 
OVFLIPGE = OVFL1PGE +1; 
LINECNT = 3; 
WRITE FILE (LISTING) FROM (OVFLL1); 
WRITE FILE(LISTING) FROM (OVFLL2) ; 
SUBSTR(PRINTLINE,1,1) = : 
END; 


WRITE FILE(LISTING) FROM (PRINTLINE); 
LINECNT = LINECNT +1; 
PRINTLINE = ''; 
END PRINT; 


END BDEBQB; 


C.1.2 RUNNING THE SAMPLE PROGRAM 


The OS/VS JCL in Figure 66 on page 157 illustrates the DD statements need- 
ed to run the sample program. The example will read a tape, but the input 
could be direct from diskette if the host system has a diskette reader. 
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//BDEBQB JOB BDEBQB,'BUILD BQBLIBI' 

//GO EXEC PGM=BDEBQB, PARM=' ISASIZE(07K) ,R/V55L66' 
//STEPLIB DD 
//BDETAPE DD 
// 


//BQBLIBI DD 
//LISTING DD 
//SYSPRINT DD 
//PLIDUMP DD 


// 


DSN=DPCX.BDE.PGM, DISP=SHR 
DSN=PNLBCKUP , VOL=SER=UKATST , UNIT=TAPE, 
DCB=(RECFM=FB , LRECL=128 , BLKSI ZE=2048 , DEN=3 ) 
DSN=BQBLIBI , DISP=OLD 

SYSOUT=A 

SYSOUT=A 

SYSOUT=A 


Figure 66. JCL to run sample PL/1 program to build BQBLIBI: JCL 
statements such as these would be used to run the sample 
program which builds BQBLIBI on an OS/VS system. 
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C.2 PROGRAM FOR HOST-INITIATED SUBTASK 


The program which is listed below may be initiated as a subtask by the 
host and will issue DPCX commands. Most commands will need to be contained 
in PROCs to allow their invocation from user number 251 under which the 
sub-task runs. A diagram illustrating the program flow may be found in 
Figure 67 on page 159. 


In the picture, and in the source listing below, the copy of the program 
running as the host initiated subtask is designated as mode 'AAAA'. The 
commands are sent as messages from the host to a reserved user number. The 
host-initiated subtask initiates a second copy of itself running under the 
res2rved user number. This is labelled mode 'BBBB' in Figure 67 on page 
159 and in the program listing, and it retrieves the messages from the 
host and passes them in 4-byte notes to the original subtask initiated by 
the host (AAAA). This in turn initiates the SYSCTL3 System Service as a 
subtask as described in "Controlling the Execution Sequence” in the DPCX 
Programming: Guide to Program Structure manual. 


The indication of success or failure returned by SYSCTL3 is reflected by 
the subtask (AAAA) in a message to the host, as are any errors encountered 
and messages issued by the invoked PROC or command. 


The program may also be invoked from a PROC in an “CALL statement. When 
used in this manner, the program will write the passed data as a message 
to the host. It may be used exactly where an “CO statement would be used to 
inform a terminal operator. The copy of the program performing this func- 
tion is referred to as mode 'CCCC' in Figure 67 on page 159 and the pro- 
gram listing. 


Before deciding to use this technique, you should also read "Maintaining 
the Message Dataset" on page 168 for a precaution which will need to be 
taken to ensure that the message dataset does not start to fill with data 
which will not be retrieved. 


Note: The use of this program with Host Prep SYSINFOREF gives the user 
access only to a subset of the function available to the user of Host Com- 
mand Facility (HCF), and this method is not a generally viable alternative 
to the use of that product. 
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HOST SYSTEM 


A 
C: Call G: Getmsg H: Retrieve Host Msg 
R: Return P: Putmsg 5S: Send Message 
I: Initsub N: Sendnote/Recnote 
/ 
USER 150 \ USER 251 (HOST) 
/ 
\ 
<-3 I 16 H 
5 N-> 6 I-> 
PGM304 PGM304 SYSCTL3 
<-14 N 
A 
7C | 
| 13 R 


DPCX PGM304 
MODE 
COMMANDS ‘CCCC* 
1s 15 P 
| | | 
V V V 
USER 150 USER 251 (HOST) 


tr 
rg 


DPC X MESSAGE DATASET 


Figure 67. Schematic of the operation of sample program 304: how 
its different functions work to allow SYSINFOREF to 
execute commands at DPCX. Numbers depict the sequence of 
execution; 'E' an error flow. 
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C.2.1 SOURCE OF SAMPLE PROGRAM. 


EEC EN GOEL ENA ECE ED EC EV ATER ED ICEL OVALE EV ED TREC EC ET EV ISIE ELISE ET VIVAL EL EV GLEN EVAL IL EDT EDEL EDEL EL EVEL IV IVES ESOL IVETE EVIL EVOL IV ED ECOL EV ICED | 


* ASSEMBLER VARIABLES * 
ve ri 


“TCLA “BUSER, ‘&PGMID 
LCLA &DEST1 ,&COMM1D ,&COMM1E , &COMM1T ,&DEST2, &COMM2 


v 

* %%k% REDEFINE THE FOLLOWING TO SUIT YOUR INSTALLATION'S CONVENTIONS 
&USER SETA 150 RESERVED USER NUMBER TO RECEIVE HOST MESSAGES 
&PGMIL SETA 304 PROGRAM NUMBER | 

&DEST1 SETA 81 FOR INTER-TASK COMMUNICATION BETWEEN 
&COMM1D SETA 91 THE TWO COPIES OF THE PROGRAM WHICH 

&COMMIE SETA 92 ARE RESPECTIVELY THE HOST-INITIATED 

&COMM1IT SETA 93 AND MESSAGE RETRIEVAL SUBTASKS 

&DEST2 SETA 82 FOR INTER-TASK COMMUNICATION BETWEEN THE 
&COMM2 SETA 94 HOST INITIATED COPY OF THIS PROGRAM 

* AND THE SYSCTL3 SUBTASK IT CREATES 
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ICO AC LTTE ET ICEL AN GREE IL ECE ED OV ET ANTE ESTO IU ELEY ICID ED ON IE EC EL TEC IDES IV ED IVES IVES ED ED TU ED GEIL TIT IV IV ED IV ED TE ID EV IN IC IVI IN GV ED EV ICIS EV ING 


* te 
* PROGRAM START, DATA AREAS AND FUNCTION DETERMINATION * 
* # 


Las ten anlar tates oles ales ater ole mlomtontamtantenlantas ate ntantontontantsatentantsntenteatentasntantentsntantontantsntasatententantenlontsntantentsatontantsntentantsntantantsntaalsntaentsatententasalentcutantesntacntentamlontantas 
rh GC AIV GV GD av edV av evVT ad 7 GR ID EL ID IDV AV IV IE IV IV GH IV EV ID IV GL GD EL ID CD IH GE FD ED IY CN weaves FO FLED FR GR EV IV JD IV EV AV GD EE GV IT IV GV IT FY EV IV IV EV IL AV IVEY AE ED ED 


STARTPGM PGMID=&PGMID, ENVIR=NOPRI ,NAME='CALLCMD' ,OPSEL=NO, % 


PRI=NONE 

SPACE 2 

DEFINE DATA 

DEFINE BUF=1 HEADER FOR SYSTEM SERVICE 
HDR FLD LVL=2,LNG=40 
SMN FLD LVL=3,LNG=4 ,TYPE=AN 
PGMID FLD LVL=3,LNG=4 ,TYPE=AN 
OPID FLD LVL=3,LNG=3 ,TYPE=AN 


TERMCD FLD  LVL=3,LNG=1,TYPE=X 
RESERV1 FLD LVL=3,LNG=6 
DESTID FLD LVL=3,LNG=3,TYPE=N 
COMMID FLD LVL=3,LNG=3,TYPE=N 
RESERV2 FLD LVL=3,LNG=16 


CTL3 FLD LVL=2,LNG=4,TYPE=E ,OCCURS=20 
DEFINE END 
SPACE 2 
* FIRST SEE IF WE HAVE BEEN CALLED FROM A PROC TO RETURN 


A MESSAGE TO THE HOST, IN WHICH CASE BUFFER1 WILL BE 
* SET UP AND WILL HAVE '*CALL' AT POSITION 40. 


SRC BUF(1),L=40,LNG=5 
COMP ‘*CALL' 
GOTOC EQ,ENQMSG 


* NOW DETERMINE WHETHER THE SUBTASK IS RUNNING UNDER THE 
* MSG USERID - IT WON'T BE WHEN THE HOST INITIATES IT. 


SRC "SUSER' 

DEST REG(3) 

SRC  USERNO 

DEST REG(2) 

COMP REG(2),REG(3) 
GOTOC EQ,COPY2 
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hase abe onl ce Pan cafes enlace las olan lacs oaPce elas malas alae wales mace an fas oxfate males anton axles onPar en bas online alan on Pew man on! ae mar Poe ben elas ten wo lae wlan onl an onl ce ten mle mien mates on! ce nln mie mis mle mts mls ule ole col, alsaleatsal, ala nfaataiateatente ealontontanteateatent mle nla ute 
GU GR IV EY IDV GUL GV EV EV ED GL GRAVY IT IV GE GD ERT GL ED GL GR ID ER ED AV EV IE ID EV CD GR FV IE FV EV EV IE CD CS ER GL FY FR EL CD ED GD CD rive iy qv ee 7 ae a av ee ev ahd CAM AMARA Ad A’ hy ae aw aR 


ate ules 


' ' | 
* PROCESSING FOR MODE  AAAA % 
. “ 
PRR TRE REE ERE EREREER ERSTE ERR EEREERERREERREEREREERERERERERERERERERSEERERERERE 
we | | | 
* RE-INITIATE THE SUBTASK, THIS TIME FOR THE MSG USER. 
ole 
AY 

SRC PGMID 


DEST REG(2) 
INITSUB REG(2) ,USERNO='&USER' 
GOTOIF I(39),ON,NORESORC 


* LOOP ROUND ASSEMBLING MESSAGES. 


LOOP FREE BUF(1) CLEAN OUT BUFFER 
ZERO REG(5) 


* WAIT FOR A BIT OF DATA. 


LOOP1 ZERO REG(6) 
INCR REG(5) 
RECNOTE DESTID='&DEST1' , TYPE=WAIT , COMMID=REG (6) 
GOTOIF I(38),ON,NODISK 
GOTOC X'01',RECERR 
GOTOC X'02' ,NODATA 
GOTOC X'04' ,DATA 
GOTO RECERR 


* NOTE RECEIVED WITH DATA. 
DATA DEST FLD=CTL3,I=REG(5) PUT IT IN THE RIGHT PLACE 
SRC REG(6) 
COMP '&COMM1D' IS IT EXPECTED? 
GOTOC NE,RECERR 
GOTO LOOP1 | 
* NOTE RECEIVED WITH NO DATA - SHOULD BE END OF 
* MESSAGE OR END OF TASK. 
we 
NODATA SRC REG(6) 
COMP '‘'&COMM1T' IS IT NOTIFICATION OF TERMINATION? 
GOTOC EQ,DONE 
COMP '&COMMI1E' IS IT END OF MESSAGE? 
GOTOC NE,RECERR 
we 
* BUILD THE SYSTEM SERVICE HEADER. THE MESSAGE RECEIVED 
* FROM THE HOST IS PASSED AS THE SYSCTL3 PARAMETER. 
SRC "SDEST2' 
EDT LNG=3,JS=R,FILL='0' 
DEST FLD=DESTID 
SRC "&COMM2' 
EDT LNG=3,JS=R,FILL='0' 
DEST FLD=COMMID 
SETMASK OFF ,FLD=TERMCD ,MASKVAL=11111111 
SETMASK ON, FLD=TERMCD , MASKVAL=00100000 
* INITIATE SYSCTL3 AS A SUBTASK. 


INITSUB PGMID=2616 
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GOTOIF I(39),ON,NORSRC1 


oF 


+ 


WAIT FOR NOTIFICATION OF COMPLETION. 


RECNOTE DESTID='&DEST2‘' , TYPE=WAIT , COMMID='&COMM2' 
GOTOIF I(38),ON,NODISK 
GOTOC X'03',RECERR 


ole 
AY 


“ BUILD STATUS MESSAGE FOR HOST. 


DEST BUF(1),L=18,LNG=4 
COMP '‘'AOOB' 
GOTOC EQ,GOOD 
COMP '9O0FO' 
GOTOC EQ,BAD 
SRC 
GOTO JOIN 
GOOD SRC ' GOOD ' 
GOTO JOIN 
BAD SRC ' BAD ' 
JOIN DEST BUF(1),L=22,LNG=5 
SRC ' STATUS FROM ' 
DEST BUF(1),L=27,LNG=13 
SRC Vostok 1 
DEST BUF(1),L=14,LNG=4 
PUTMSG  CALLSUB HOSTMSG 


GOTO LOOP 
* NO MORE MESSAGES FROM HOST FROM COMPANION TASK. 
DONE EXIT -; ALL DONE 
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le 
@ 
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» 


ake 
ww 


ale 
@ 


¢ 


ale 
ev 


PROCESSING FOR MODE '‘BBBB' ve 


mte 
Cay 


GV OL EV AV EL ERED AR EE EL AE I ED IE AL GE GE AN OD OD GN GD AE AR AE IR EE AN GD IE GR OD IRIE ED AN GR AR EE AE IR EE EN AE AR ER AN ER ER EL IN EL CE EL EVIL GL EL AV SV EL EL GE GV EL GD IN EL ON ONG 
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ZERO 


GET A MESSAGE, UNKEYED, FOR THIS USER AND PROGRAM. 


REG (4) COUNTER OF HOST MESSAGES PROCESSED 


GETMSG THISPGM 
GOTOIF I(38),0N,DONE2 


INCR 
ZERO 


CYCLE 
INCR 
SRC 


REG (4): COUNT THIS MESSAGE 
REG(5) | 


SEND MSG IN 4-BYTE NOTES TO THE HOST-INITIATED SUBTASK. 
20,ENDC 


REG(5) 
BUF(1),L=0, LNG=4, I=REG(5) 


SENDNOTE DESTID='&DEST1' ,DATA=YES , COMMID='&COMM1D' 
GOTOIF I(38),ON,NODISK2 
ENDCYCLE 


INDICATE END OF MESSAGE. 


SENDNOTE DESTID='&DEST1' ,DATA=NO ,COMMID='&COMM1E' 


GOTO 


LOOP2 


NOTIFY THE HOST INITIATED SUBTASK OF TERMINATION. 


SENDNOTE DESTID='&DEST1' , DATA=NO , COMMID='&COMMIT' 
GOTOIF I(38),ON,NODISK2 


EQU 
SRC 
COMP 
GOTOC 
EXIT 


REG (4) DID WE GET ANY MESSAGES FROM HOST? 
0 

EQ, NOTHING 

, ALL DONE 
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qy 
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PROCESSING FOR MODE 'CCCC' 


ole 
ray 


ole 
ray 


ERI EL ERED ER GL AVAL IE IE ED ED IVER AL IE ID EL IVIL TIE IS AV TIL IN AL AV AL ER AR GL EL EL EL EDEL ER EVEL GD INAV ER AL IL ANGLIN GL GL EL EL EL ALIN GL ER GR GD ER ER ON OR OR Ad 9 48 98 


* 
* 
ENQMSG 


SRC 
DEST 


SRC 
DEST 
SCAN 


SCAN 
SCAN 


ADD 
SCAN 


ADD 
SCAN 


ADD 
SRC 
DEST 
SRC 
DEST 


CALLSUB HOSTMSG 


SRC 


ENQUEUE REQUESTOR'S MESSAGE TO HOST. 


"956! 
REG(1) 


MOVEBUF FROM=BUF (1) , TO=BUF (2) , LNG=REG (1) SAVE ENTIRE BUFFER 
120 


REG(2) 

BUF(2),MOVE=NO, | ESTABLISH LENGTH OF COMMAND IMAGE 
FLD=CTL3 , STOP=(X'00' ,EQ) ,CNT=REG(2) , LNG='120' 
BUF(2),MOVE=NO, SCAN PAST *CALL 

FLD=CTL3 ,STOP=(' ',EQ),CNT=REG(3) , LNG=REG(2) 
BUF(2),MOVE=NO, SCAN PAST BLANKS 
FLD=CTL3 , D=REG(3),STOP=(' ',NE),CNT=REG(1),LNG=REG(2) 
REG(3) ,REG(1) 

BUF(2),MOVE=NO, | SCAN PAST PROGRAM NUMBER 
FLD=CTL3 , D=REG(3),STOP=(' *',EQ),CNT=REG(1),LNG=REG(2) 
REG(3) ,REG(1) 

BUF(2),MOVE=NO, SCAN PAST BLANKS 
FLD=CTL3 , D=REG(3),STOP=(' ',NE),CNT=REG(1),LNG=REG(2) 
REG(3) ,REG(1) 

BUF (2) , FLD=CTL3 , D=REG(3) , LNG=REG(2) 

BUF (1) ,FLD='25' , LNG=REG(2) 

'FROM PROC: ' BUILD MESSAGE 

BUF (1) ,L=14, LNG=11 

ENQUEUE TO HOST 

'256' 


DEST REG(1) 
MOVEBUF FROM=BUF (2) ,TO=BUF(1),LNG=REG(1) RESTORE ENTIRE BUF 


RETURN 


; SO AS NOT TO CHANGE THE PROC'S ARGS 
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FV ECV EV GV IV EDV FV EL ED EL GV ED FT EV CO EV IV ECV ED IBID GID EV IV ID FE FD IH IV IVIL IVT IE EDITED IR EVEL IE CV FV FR IR EIV IVES CD EVEL EY IV EH IE FD TH IT ID ID CY wes VIVID EDV EDL ID ED FY 
ale ale 
qa «ey 
ole : ale 
@e CAS 
ale ates 
qe cay 


JEL IV AVIV GL EV IVE AL IEEE AV EVIE ET IL EL EDEL ED ED TOES TD ED IDES ERED GLEN TV IS ED ID ED ED EDEN TE EL ED EVID ED EVES ED ID OO PN EV EV ET EV ADIL ET EV ENED ET EN SUID GO GS SO Se 4B 


* SUBROUTINE TO ENQUEUVE MESSAGES TO THE HOST. 
* INCLUDE DATE AND TIMESTAMP. 


HOSTMSG SRC’ DATE 
TRNSLAT ALL,OLD=X'00' ,NEW='0' 
DEST BUF(1),L=0,LNG=6 
SRC TIME 
TRNSLAT ALL,OLD=X'00',NEW='0' 
DEST BUF(1),L=7,LNG=6 
SRC ' ' 
DEST BUF(1),L=6,LNG=1 | 
DEST BUF(1),L=13,LNG=1 


be 


QUEUE THE MESSAGE FOR THE HOST. 


oh ob 


SRC 251" 

DEST REG(3) 

SRC  PGMID NOT RELEVANT FOR MESSAGE TO HOST 
DEST REG(2) .... BUT MAKE SURE IT'S VALID 
PUTMSG REG(3),REG(2) 

RETURN 
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qa ri ED FR IV ED EDV EH CV FR IHW GV EH CHV IB EV FV FH IV GV AV IV IH ID IV CH CD ID IL IV GH IH ICD EL FH ID GH CD CY CH IH IH IT ID SO ER ED FE GL GD CD 

#, 
ve we 
* ERROR ROUTINES * 
ae rind 
PAY 


TSH CAC AE aS aN EC ae IN AU CC AL ICID ODOC GN EE TEAL TE EL ICED ATEN TED EO EC FC ERIS TRIES TT EDEN ITUNES ED UDINE ET ED IN EO EO TV ENED ESE ED EV INED EV EV EVEN EV ED ENG 


PREV ILIV ED IV EL EEL GD IL GE dL EL CE ID OD CV OD FR OD 


w EXCEPTION CONDITIONS. 
3 
NORESORC SRC "INSUFFICIENT RESOURCES TO START SUBTASK FOR OPID &USER' 
DEST BUF(1),L=14,LNG=200 
CALLSUB HOSTMSG 
EXIT 
we 
NORSRC1 SRC "INSUFFICIENT RESOURCES TO START SYSCTL3' 
DESTMSC DEST BUF(1),L=14, LNG=200 
GOTO PUTMSG 
ve 
NODISK SRC "INSUFFICIENT DISK FOR RECNOTE' 
GOTO DESTMSG 
we 
RECERR SRC "UNEXPECTED CONDITION CODE FROM RECNOTE' 
GOTO DESTMSG 
w . 
NOTHING SRC "NO MESSAGES RECEIVED FROM THE HOST' 
DEST BUF(1),L=14,LNG=200 
CALLSUB HOSTMSG 
EXIT 
ve 
NODISK2 SRC "INSUFFICIENT DISK FOR SENDNOTE' 
DEST BUF(1),L=14, LNG=200 
CALLSUB HOSTMSG 
GOTO EXIT2 


w 


ENDPGM 
END 
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C.2.2 MAINTAINING THE MESSAGE DATASET 


DPCX command processing routines invoked by SYSCTL3 use inter-task commu- 
nication notes and messages to pass information back to other routines 
controlling the operator's terminal command session. Whilst the messages 
are retrieved to the host, the notes which are enqueued to Destid 236 and. 
a Commid of the user number, in this case 251, are never received because 
no terminal session can occur for this user. In consequence, notes to des- 
tid 236 will gradually accumulate, and in time will start to degrade DPCX 
performance. 


The simple program shown in Figure 68 will delete notes to destid 236 from 
the message dataset. It is best called from the IPL PROC with an *CALL 
statement, as there is then no risk of it disrupting processing for other 
operators. 


STARTPGM PGMID=305 , ENVIR=NOPRI , PRI=NONE , OPSEL=YES, 
ACCESS='11111111' ,NAME='PURGNOTE' 

SRC X'O1EC' KEY FOR NOTES TO DESTID 236 

DEST DSINDEX 

DATASET DSID=6 ,CONTROL=YES 

DRL KEY1,BLOCK=0 

EXIT 

ENDPGM 

END 


Figure 68. Program to maintain the message dataset: this program 
will clean out the system-generated notes relating to 
user number 251 which are never retrieved. 
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D.Q SAMPLE FORMS 


This chapter contains the examples of forms for the following purposes: 


Maintenance log of system software changes applied to a DPCX/DOSF sys- 
tem: Figure 69 on page 170. 


Reference application programs installed to SYSINFOREF versions and 
levels: Figure 70 on page 171. 


Maintenance log of application software 
tem: Figure 71 on page 172. 


Recording SYSIMOD option 
on page 173. 


Recording SYSIMOD option 
on page 174. 


Recording SYSIMOD option 
on page 17/5. 


Recording SYSIMOD option 
on page 1/76 and Figure 76 


Recording SYSIMOD option 
on page 178. 


Recording SYSIMOD option 
on page 179. 


Recording SYSIMOD option 
on page 180. 


group l 
group 2 
group 3 
group 6 
on page 
group /7 


group 8 


group C 


values 


values 


values 


values 


Lets 


values 


values 


values 


installed on a DPCX/DOSF sys- 


for 


for 


for 


for 


for 


for 


for 


a DPCX 
a DPCX 
a DPCX 
a DPCX 
a DPCX 
a DPCX 


a DPCX 


system: 


system: 


system: 


system: 


system: 


system: 


system: 


Figure 


Figure 


Figure 


Figure 


Figure 


Figure 


Figure 


72 


73 


74 


75 


77 


78 


79 


Recording RJE logon information for a DPCX system: Figure 80 on page 


181. 


Recording RJE FCB definitions: 


Recording DOSF values for a DPCX system: 


Recording DTF session definitions for a DPCX system: 


page 184 and Figure 84 on page 185. 


Recording device addresses, 


types, 


DPCX system: Figure 85 on page 186. 


Figure 81 on page 182. 


Figure 82 on page 183. 


Sample Forms 


Figure 83 on 


identities and locations for a 
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System _ i OS aE en nee Name 


of Batch LU 
Product Update Level, Date 
Identifier Fix Package Installed 


or PTF Id. 


Figure 69. Form to record system software updates: this may be 


used to record the installation of service to system 
software on a DPCX/DOSF system. 
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Product or Product, PTF or SYS INFOREF 
Module Identifier Apar Level Version Level 


Figure 70. Form to record SYSINFOREF versions and levels: this may 


be used to record the version and level numbers assigned 
to application entities as they are loaded on the 
SYSINFOREF library. 
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System a eee ere Name , 


of Batch LU 
Product or SYS INFOREF Date 
Module Identifier Version Level Installed 


Figure 71. Form to record application software installation: this 
may be used to record the installation of application 
software on a DPCX/DOSF system. 
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SYSIMOD (1) VALUES System _ at 
(HOST OPTIONS) 


Transaction Record Packing: 

Transmit Record Blocking: 

Connection Retry Counter: 

Open Retry Counter: 

Station Id: 

Station Address: 

Connect-Modem-to-Line Circuit: eas 


(Used by Modem: Yes = 1, No = 2) 


NRZI Encoding for Modem: as 
(NRZI = 1, not NRZI = 2) 


Line Type: 
(Leased = 1, Switched = 2) 


Modem Generates Tone: Rae 
(Yes = 1, No = 2) 


Permanent Request to Send: — 
(Modem can operate with: Yes = 1, No = 2) 


Automatic Tests: ees 
(Yes = 1, No = 2) 


Read / Idle Timeout Counter: 


Figure 72. Form to record SYSIMOD option group 1 values: this may 


be used to record the values for SYSIMOD option group 1 
which describe the host connection. 
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SYSIMOD (2) VALUES System at 
(PRINT GROUP TABLE) 


Enter number of sets of 256 records required for each print group: 


Le ee K2Z56°° Di KIO. Bo ee 5 R256" 9G ee RZ9NG 
Oe tei RZOO (62) zi RZ56 PS iets KEIO TOS gotta, RZ OO 
O© 2225. KZ56. 102.222 4296 TIS 2 KZ56: 12s pK Z56 
13S oa BZDO. AAS oa SKOOL a RISO «16S... KZ56 
17; _. 256 «6218: _sCi256 «8619: _ sx 256 «220: _ ss X25 6 
21: _s x2560 «22: _ iC 256 «823: _sCix256 «024: _ ss X25 
POF ices B2ZOO- 208 to KZ90 27 te es KRZOO =3-28 Fu, KZ56 
29?..2. 5 nt R2D6-- 302-22 E256 OT. uo RZOG LOZ R256 
33: x256 34: ____s x256 «35: ___s x256 «36: ___s-x256 
BIS ice R296, “BSS ee ROO: OOF, cn R250 405. R256 
41: _ x256 0 «642: _ ss 256 «6243: _ i256 «8244: _ ss X56 
AO 8) oo (RZ56. GOS ae 2 K2O6. (OTS = XZ5O (4G on R250 
AO so (KZ56 50% no 256 Sn . KZ56) (92. eo, B56: 
Oe ee MOO USA oe MOG. OOP pa ROO: SOF 5 KIC 
57: __ Sx256) «58: __sCi 256 «659: LC K256 «68660: sé 2256 
61: xX256 62: __ ss k2560 «63: __E C256 «8264: _sCé 2256 


Figure 73. Form to record SYSIMOD option group 2 values: this may 


be used to record the values’ for SYSIMOD option group 2 
which define the print group table. 
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SYSIMOD (3) VALUES System _ at 
(TRANSACTION DATA SET GROUP TABLE) 


Enter number of sets of 256 records required for each TDS group: 


1: _. ss X56 2: _ ss X 256 Bee ar eK ZOO 
WS OO De at XZOO 65 on ., KZIG 
Te ta XZ IO 8: _ ss 256 Oe. ia X20 
LOS ete X256 ae 2 “XZO6 Ly ect KZ OO 
TSF ane ADO 14: ___s 256 15: _ KX 256 
TGs occ KZOC ATS ees KZ250 TG: 2. (X20 
19: _ ss X256 20: _ ss X256 Dee oe RZ 
1) X256 BOS ni LOO 24: _. -x¥256 
29 22.2 R256 26: _ ss X26 27: _s X256 
28: _ X256 298 ee OR Z5O 90% 222-2 (R296 

31: x256 32: x256 


Figure 74. Form to record SYSIMOD option group 3 values: this may 
be used to record the values for SYSIMOD option group 3 


which define the transaction dataset group table 


Sample Forms 
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SYSIMOD (6) VALUES System | at 
(LU - LA TABLE: PART 1) | 


Host LU Number DPCX Terminal LA Printer Group/Mode 


Figure 75. Form to record SYSIMOD option group 6 (part 1) 


values: this may be used to record the values for 
SYSIMOD option group 6 which define part 1 of the LU-LA 
table. 
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SYSIMOD (6) VALUES System at 
(LU - LA TABLE: PART 2) | 


Printer Group Number - - - = Assigned LAS - - - - 


Figure 76. Form to record SYSIMOD option group 6 (part 2) 


values: this may be used to record the values for 
SYSIMOD option group 6 which define part 2 of the LU-LA 
table. 
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SYSIMOD (7) VALUES System _ at 
(RJE PARAMETERS) 


RJE Operator Number: eens: 


RJE Command Character: Bods 


RJE Transmit Chain Size: co bk 


RJE LU Numbers: i ee ee men 


Form to record SYSIMOD option group 7 values: this may 


be used to record the values for SYSIMOD option group 7 
which set the RJE parameters. 
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SYSIMOD (8) VALUES System 
(SYSTEM OPTIONS) 


1. ABEND Print Status: 
(Enable = 1, Disable = 2) 


2. DSC Mode Selection: 
(1976 = 1, 1970 = 2) 


3. Select Write Verify: 
(Enable = 1, Disable = 2) 


4. System Print Group Number: 


5. User-Defined Categories: 
(Select User-Defined = 1) 


6. Disable Assist: 
(Disable = 1) 


Figure 78. Form to record SYSIMOD option 
be used to record the values 
which define system options. 


group 8 values: this may 
for SYSIMOD option group 8 
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SYSIMOD (C) VALUES System at 
(PRINTER MATRIX FOR 8775S) 


8775 LA Associated Printer LAs 


Figure 79. Form to record SYSIMOD option group C values: this may 


be used to record the values for SYSIMOD option group C 
which define the printer matrix for 8775 display 
terminals. 
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RJE LOGON DATA System _ at 
RJE LU NAMES: 1 2 
OF ee eee ee eS ae 5 


DATA FOR LOGON-ID 1 
Host Logmode Table Entry Name: 
Host Application Name: 


Lugon User Data: 


DATA FOR LOGON-ID 2 
Host Logmode Table Entry Name: 
Host Application Name: 


Logon User Data: 


DATA FOR LOGON-ID 3 
Host Logmode Table Entry Name: 
Host Application Name: 


Logon User Data: 


DATA FOR LOGON-ID 4 
Host Logmode Table Entry Name: 
Host Application Name: 


Logon User Data: 


Figure 80. Form to record RJE logon data: this may 


be used 


record the RJE logon data for SYSRJE option 7.1. 


Sample Forms 


to 
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RJE FCB NAME: 


Maximum Page Length: 7 Sete 
Top Margin: ean eee 
Bottom Margin: Re 
Vertical Stop 1 (Channel 2): eae ete 
Vertical Stop (Channel 3): eee 
Vertical Stop (Channel 4): sees A 
Vertical Stop (Channel 5): sae 


Vertical Stop (Channel 6): eee 


Nn oO FP WO ND 


Vertical Stop (Channel 7): Sates tt 
Vertical Stop 7 (Channel 8): ees 
Vertical Stop & (Channel 9): cent ee a 
Vertical Stop 9 (Channel 10): ee ea 


Vertical Stop 10 (Channel 11): ae as 


Figure 81. Form to record RJE FCB data: this may be used to record 
the RJE FCB data for SYSRJE option 7.1. 
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DOSF VALUES System at 


Adjust Mode (yes or no): oe a 


Line Width: 


Lines per Page: 


Tab Stops: 
1 eee ? A eee 3: Oe eee 5 
Oy violets De tt eae ee 10: 
PA ett 5). a | ES ae eee | ee 15: 
TGS 1 ae ae 1 |e |: ae 20: 


Overstrike Character: Lae 
Spaces text <---> line number: ae 
Hyphenation Zone Width: | == 
System Identification Code: eee 
Date Representation: aoe 
(1 = MMDDYY, 2 = DDMMYY, 3 = YYMMDD) 


Automated Text Operator: 


Data Dictionary Dataset: 


Figure 82. Form to record DOSF values: this may be used to record 


the DOSF values set with SYSXGEN or changed with 
SYSXMNT. 
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DTF SESSION System _ at 


Session: eres See aa Re err LU Name: 
Logmode: Se ee LU Number: ee 
LU Type: oe Applname: 


(1 = LU 1 single chain, 2 = LU 1 multiple chain, 
3 = LU O no RU padding, 4 = LU O RU padiing) 


session End Prog.: Max. Doc. Size: 
Default Operator No.: __. Normal Running Mode: 
(1 = Open, 2 = Closed) 
Max. Chain Size: Pad Character in Hex: 
Terminator: __ Session Initiation: 


(1 both, 2 = DOSF, 3 = Host) 


Autoshutdown: sree Recoverable: a 
(1 = yes, 2 = no) (1 = yes, 2 = no) 

Allow Unlisted Queues: ae Action on Error: 

(1 = yes, 2 = no) (1 = next queue, 2 = stop) | 


Figure 83. Form to record DTF session definitions: this may be 
used to record the values used with SYSXSDEF to define 
DTF sessions. 
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DTF SESSION QUEUES System 


Session: 


QUEUES TO SEND: 


Queue Name: 


Action on Error: 
(1 = 


next element, 2 = stop) 


Send Queue Element Id.: 
(1 = yes, 2 = no) 


Queue Name: 


Action on Error: Sts 
(1 = next element, 2 = stop) 


Send Queue Element Id.: 
(1 = yes, 2 = no) 


a 


QUEUES FOR RECEIPTS: 


Queue Name: 


Queue Name: 


Form to record 


sessions: this 
characteristics 


Figure 84. 


may 
of the 


queues 


be 
queues to be used with a 


at 


LU Name: 


When to Process: peers 
(1 = always, 2 = host req.) 


Transaction: 


When to Process: eer 
(1 = always, 2 = host req.) 


Transaction: 


Solicited Documents: 
(1 = yes, 2 = no) 


Solicited Documents: 
(1 = yes, 2 = no) 


for transmission on 
used to record 


session defined with SYSXSDEF. 
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DEVICES CONFIGURED System at 


LA PA Type Serial Location 


nenairanntamanctniadiieecmibecirerncrermcei  admrcmetememesereces = = akeambyemmenaemcbetateebiosbertee create Re HTEETRUSERTESASESSSEERS «= fans p-TSURLLSSHEURENIDEa ances tne DAE A a RES 
ianbtoessenelineietvcmbtconmemecmeredemitsmniiiecss == athattatctae ani =cut MAL ETNA Mencugcr seme tech MARMARA ECARAASSIAEROSERENC Meh eft en tinea 
Arai eom ie == C aia atte ah ane adalat SRA ERLE i aunts  tc naapdieM ih at Rrteta 
remanence  «=é§ = eenemebnmecee == Gbtnimuunetemrinininentnnnemiteamnnenitnnnstnnemieinminemeserminiaiin® = chan apr ant SRS SUT ERI VATE TOSSES 
Rane ICR ITI ETEN SST = AMEN = aera nee honthireainthentinnictiancnmnCISSIELINAI TATRA ASAIORCNRIISED ces Rar mn arc anor nti NTRS CARE 


aA AAL DATEL AERA PORE NRA Mania tne ee at at est CEDRUS == ame srt ie le PR SSS SERIES 


temanctemorseatisinerinatmitanteetetteikaeash = eainrAincmee  =«§«»«« (bmp htniycRch Rm ANTENiceanenanihreie® «= cejustentchenecene ncn uh mbes reg AAT ALES ACCRA 


Figure 85. Form to record the configuration of devices on a DPCX 


system: this may be used to record the addresses, 
types, identities and locations of devices attached to a 
DPCX/DOSF system. 
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This bibliography is organised in 
alphabetic sequence of titJe. A 
full list of all the system ref- 
erence library manuals in the 
DPCX/DOSF family is contained in 
the DPCX/DOSF Guide to Books. The 
DPCX/DOSF Master Index and Glos- 
Sary contains an index of topics. 


SX27-0060 DOSF Installation Card 
for ASSIST. This card 
documents and illus- 
trates the steps of 
installing DPCX, DOSF 
and IDTF with ASSIST. 


$C27-0556 DOSF Planning. 


This book explains how 
to plan the use of DOSF 
and write directions 
for its installation, 
configuration and sub- 
sequent operation. 


$C27-0553 DOSF System Services. 


This book is a refer- 
ence for anyone who 
uses the DOSF system 
services. 


$C27-0639 DPCX/DOSF Basic Oper- 
ations. 


This book introduces 
DPCX and describes bas- 
ic operating procedures 
for the control opera- 
tor to use when operat- 
ing DPCX/DOSF. 


S$C27-0637 DPCX/DOSF Command Pro- 
cedures. 


This manual contains 
reference information 
about the command pro- 
cedure control commands 
and arguments that are 
used within PROCs. 
Examples of PROCs are 
included to show some 
of the things a PROC can 
do. 


BIBLIOGRAPHY 


$C27-0520 DPCX/DOSF Command Ref- 
erence. 


This book describes the 
commands that are used 
to operate a DPCX DOSF 
system and how to log 
the activities at an 
operator's terminal. 


$C27-0537 DPCX/DOSF 
Guide. 


Diagnosis: 


This publication dis- 
cusses the DPCX and 
DOSF service aids that 
are available to help 
to identify problems 
within a DPCX system 
after it has been suc- 
cessfully installed. 


GC2/-0640 DPCX/DOSF Guide to 
Books. 


This book lists the 
books needed to use 
DPCX and DOSF. 


SC27-0484 DPCX/DOSF 


tion. 


Installa- 


This book sets out how 
to install and config- 
ure DPCX and DOSF, with 
information about PTFs 
and ASSIST installa- 
tion. 


GC22-9087 DPCX/DOSF Master Index 
and Glossary 


This book contains 
information about top- 
ics and terms from the 
8100/DPCX/DOSF system. 
The Master Index lists 
which topics are cov- 
ered by which books, " 
and the Glossary 
defines terms. 


$C27-0523 DPCX/DOSF Messages and 
Codes 


This book lists’ the 
messages and codes pro- 
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duced by DPCX and DOSF, 
with an explanation of 
each and suggested 
actions and responses. 


SC27-0482 DPCX Planning. 


This manual describes 
selected aspects of 
planning applications 
to use with DPCX. 


$C27-0487 DPCX Programming: Guide 
to Host Communications 
for System Programmers. 


This manual describes 
the facilities of DPCX 
systems which are used 


during communication 
sessions with the host 
system. 


$C27-0490 DPCX Programming: Guide 
to Program Structure. 


This book explains how 
to write programs for 
an 8100 running DPCX as 
the operating system, 
with reference to using 
program resources, per- 
forming arithmetic and 
logic operations and 
controlling the program 
sequence. 


$C27-0486 DPCX Remote Job Entry: 
Installation and Opera- 
tion. 


This book tells how to 
install and operate the 
RJE facility of DPCX. 


$C27-0492 DPCX System Services. 


This book describes the 
System Services the 
control operator uses 
when operating an 
8100/DPCX system. 


$C27-0483 DPCX Terminal Oper- 
ations: Program Exe- 
cution Monitor Guide 


This manual describes 
the use of the Program 
Execution Monitor (Sys- 
tem Services SYSDEBUG 
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and SYSTEST) to monitor 
and test DPCX programs. 


$C27-0455 HCF Guide and Refer- 
ence. | 


This manual presents a 
general introduction to 
HCF, provides informa- 
tion on planning for 
its installation and 
specific information 
for its operation. 


S$C27-0577 Host Prep: Guide to 
Host Services. 


This book explains how 
to prepare programs, 
panels and datasets for 
end use at a DPCX sys- 
tem. 


SC27-0580 Host Prep: SYSINFOREF 
Guide and Reference. 


This book describes the 
SYSINFOREF portion of 
the Host Prep program 
products, with examples 
of its use and a com- 
plete reference of its 
control statements. 


GA27/7-3341 IBM Multiuse Communi- 
cation Loop Planning 
and Installation Guide. 


This manual contains 
detailed information on 
designing and planning 
a loop configuration, 
and on instailing and 
testing the loop cable, 
hardware and loop 
accessories. 


 GC34-2027 Information/System 


General and Preinstal- 
lation Information. 


This document provides 
a general introduction 
to, and initial plan- 
ning information for, 
the Information/System 
product and its Infor- 
mation/Management, 


Information/MVS and 
Information/Access fea- 
tures. 


GC27/-0429 NCCF General Informa- 


tion. 


This book provides an 
overview of the Network 
Communications Control 
Facility. 


GC30-3081 NLDM General Informa- 


tion. 


This manual describes 
the functions and use 


of the Network Logical 
Data Manager. 


GC34-2061 NPDA General Informa- 


tion. 


This book provides an 
overview of the Network 
Problem Determination 
Application. 
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The glossary lists abbreviations 
and acronyms used in this manual, 
giving their meanings and a brief 


description of the 
question. 


ABEND 


ACF 


AMS 


APAR 


APPLID 


ASSIST 


BDES 


BOP 


concept in 


Abnormal end: when a 
program or software 
component terminates 
abnormally. 


Advanced Communication 
Function: IBM program 
product versions of 
VTAM with the option to 
link multiple host 
domains. 


Access Method Services: 
programs for creating 
and maintaining VSAM 
datasets 


Authorised Program 
Analysis Request: the 
mechanism for resolving 
an error found in IBM 
software. 


Application identifier: 
the name and character- 
istics with which a 
host program identifies 
itself to VTAM as an 
application. 


An aid for the instal- 
lation of DPCX/DOSF 
8100 systems which per- 
forms a standard custo- 
misation. 


Batch Data Exchange 
Services: a part of the 
Host Prep program pro- 
ducts which allows 
application programs, 
panels and DSCBs to be 
written to tape or 


diskette for trans-~ 
mission to DPCX. 
Basic Operator Panel: 


the panel on the 8130 or 
8140 processor contain- 
ing the IPL switches 
and the four-digit dis- 


CICS 


CIL 


CLIST 


CNM 


DASD 


DB/DC 


DCF 


DD 


DIF 


DISOSS 


GLOSSARY 


play and keys used to 


communicate with the 
8100. 
Customer Information 


Control System: a host 
DB/DC system IBM pro- 
gram product. 


Condition Incident Log: 
the DPCX dataset in 
which error conditions 
are recorded. 


Command list: a list of 
commands for a com- 
mand-driven program. 


Communications Network 
Management: the manage- 
ment of physically dis- 


tinct, geographically 
separated computing 
resources connected by 


a TP network. 


Direct Access Storage 
Device: permanent aux- 
iliary storage. 


Data Base/Data Communi- 
cation: a system with 
structured methods of 
organising and trans- 
mitting data. 


Document Composition 
Facility: a host based 
text formatter IBM pro- 
gram product. 


Data Definition: a host 
JCL statement describ- 
ing a dataset. 


Document Interchange 
Facility: an IBM pro- 
gram product allowing 
the interchange of doc- 
uments between DOSF on 
an 8100 and DLF on a 
host system. 


Distributed Office Sup- 
port System: this IBM 
program product’ sup- 
ports central filing 
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DITTO 


DLA 


DLF 


DOS/VSE 


DOSF 


DPCX 


DPPX 


DSC 


192 DPCX/DOSF Network Management 


and retrieval of DOSF 
documents at a host 
system and electronic 
mail capabilities among 
users of a network of 
DPCX systems. | 


Data Interfile Trans- 
fer, Testing and Oper- 
ations Utility: a 


DOS/VSE program product 
with data display and 
copy functions. 


Data Link Adaptor: an 
SDLCG communications 
link on DPCX. 


Document Library Facil- 
ity: an IBM program 
product providing a 
host system with a 
library facility for 
documents to be proc- 
essed with DCF. 


Disk Operating 
tem/Virtual 
Extended: an IBM host 
operating system for 
smaller System/370 and 
4300 processors. 


Sys- 
Storage 


Distributed Office Sup- 
port Facility: an IBM 
product providing text 
processing to an 
8100/DPCX system. 


Distributed Processing 
Control Executive: an 
IBM operating system 
for 8100 processors 
supporting text (DOSF) 
and data applications. 


Distributed Processing 
Programming Executive: 
another IBM operating 
system for 8100 proces- 
sors supporting more 
sophisticated data 
applications. 


Data Stream Compatibil- 
ity: a feature of DPCX 
providing a terminal 
attached to the 
access to host applica- 
tions as if it were 


8100 | 


DSCB 


DSX 


DTF 


FCB 


FP 


HCF 


Host Prep 


IDTF 


IMS 


lIOCB 


directly attached to. 


the host. 


Dataset Control Block: 
a record that describes 
the allocation and 
characteristics of a 
dataset. 


Distributed Systems 
Executive: this IBM 
program product resides 
on a host system and 
controls data consti- 
tuting distributed sys- 
tems. 


Transmission 
Facility: a feature of 
DOSF supporting the 
transmission of docu- 
ments between an 8100 
and a host system. 


Document 


Forms Control Buffer: a 


record defining car- 
riage control for a 
printer. 

Function Program: a 


DPCX user program or 
System Service. 


Host Command Facility: 
this IBM product allows 
a host-attached display 
screen to access DPCX 
as if the terminal were 
attached to the 8100. 


An IBM program product 
providing host manage- 
ment of DPCX 8100 sys- 
tems. 


Interactive 
Text Facility; an IBM 
program product con- 
sisting of microcode 
which gives an 8775 
display terminal text 
entry and edit capabil- 
ities. 


Display 


Information Management 


System: a host DB/DC 
system. 

/ 
Input/Output Control 
Block: in DPCX, a 


IPL 


JCL 


JES 


LA 


LU 


MVS 
NCCF 


NCP 


NIM 


NLDM 


record describing an 
attached device. 


Initial Program Load: 
the function of ini- 
tialising a processor 
with an operating sys- 
tem, such as an 8100 
with DPCX. 


Job Control Language: 
statements which 
instruct a host operat- 
ing system in the proc- 
essing of programs and 
data. 


Job Entry Subsystem: a 
component of a host 
operating system 
responsible for the 
management of jobs. 


Logical Address: the 
representation of a 
device within the 
architecture of DPCX 
addressing. 


Logical Unit: the rep- 
resentation of some 
program within DPCX to 
VTAM and the NCP. 

see OS/VS2/MVS. 


Network Communications 


Control Facility: an 
IBM program product 
which assists a host 


installation to control 
and operate an SNA net- 
work. 


Network Control Pro- 
gram: the software 
which resides in a 3705 
communications control- 
ler. 


Network Installation 
Management: a capabili- 
ty of DPCX releases 3 
and subsequent to 
install new releases of 
DPCX and DOSF across 
the network from the 
host. 


Network logical Data 
Manager: this IBM pro- 


NPDA 


OS/VS1 


gram product collects 
data relating to SNA 
sessions between net- 
work resources and 
gives a user. online 
access to it. 


Network Problem Deter- 
mination Application: 
an IBM program product 
which assists a host 
installation in the 
isolation of network 
problems. 


Operating Sys- 
tem/Virtual Storage 1: 
an IBM host operating 
system for medium Sys- 
tem/370, 4300 and 303x 
processors. 


OS/VS2/MVS Operating Sys- 


PCA 


PDS 


PROC 


PSN 


PTF 


PU 


tem/Virtual Storage 
2/Multiple Virtual Sto- 
rages: an IBM host 
operating system for 
large System/370, 4300, 
303x and 308x process- 
ors. 


Primary Communications 
Attachment: a loop or 
link adaptor oon = an 
8100. 


Partitioned Dataset: A 
library file organisa- 
tion used by OS/VS 
operating systems. 


Procedure: a list of 
control statements and 
commands. 


Print Sequence Number: 
used by DPCX to identi- 
fy a set of spooled 
print records. 


Program Temporary Fix: 
a package of replace- 
ment code issued by IBM 
to correct defects in a 
software component. 


Physical Unit: the rep- 
resentation of the 8100 
DPCX system to VTAM and 
the NCP. 
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Program Validation Ser- 
vices: a component of 
Host Prep which pre- 
pares application pro- 
grams for transmission 
to DPCX. 


Remote Job Entry: a 
facility of DPCX allow- 
ing jobs to be input an 
8100 to a host system 


and printed output 
received back. 

Relative Sequential 
Dataset: a dataset 
organisation employed 
by DPCX. 

Stand Alone Save 
Restore and Diskette 


Copy Program: the name 
by which the DASD dump 
restore utility is 
known in DPCX release 
3. 


Synchronous Data Link 
Control: a link-level 
transmission protocol 
employed in IBM SNA 
networks. 


Systems Network Archi- 
tecture: an IBM archi- 


tecture for data 
communications net- 
works. 


System Services Control 
Point: the program con- 
trolling an SNA _ net- 
work, for instance 
VTAM. 


SSss 


SYSINFOREF Subsystem 


TAF 


TP 


VSAM 


VTAM 


Subsystem Support Ser- 
vices: IBM systems con- 
trol programming 
supporting the manage- 
ment of data comprising 
distributed systems; 
largely superceded by 
later IBM program pro- 
ducts. 


Informa- 
tion Retrieval Facili- 
ty: a component of Host 
Prep which communicates 
programs, PTFs and oth- 
er information between 
a host system and DPCX 
systems. 


Terminal Access Facili- 
ty: a component of NCCF 
allowing an NCCF termi- 
nal access to other 
applications. 


Tele-processing: 
descriptive of data 


communications tech- 
niques employed between 
geographically sepa- 


rated locations. 


Virtual Storage Access 
Method: a dataset orga- 
nisation and access 
method used by IBM host 
operating systems. 


Virtual Telecommuni- 
cations Access Method: 
an IBM SNA data commu- 
nications access meth- 
od. 


Staples can cause problems with automated mail sorting equipment. 
Please use pressure sensitive or other gummed tape to seal this form. 
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You may use this form to communicate your comments about this publication, its organization, or 
subject matter, with the understanding that IBM may use or distribute whatever information you 
supply in any way it believes appropriate without incurring any obligation to you. 

Your comments will be sent to the author’s department for whatever review and action, if any, is 
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Possible topics for comment are: 


Clarity Accuracy Completeness Organization Coding Retrieval Legibility 
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